こんにちは！インフラ構築やクラウドの安全性を日々守るセキュリティエンジニアの仲間として、今回は皆さんと一緒に「Infrastructure as Code（IaC）の静的解析」について紐解いていきたいと思います。
突然ですが、皆さんは家を建てる時、頑丈な鍵をつけたり、泥棒が侵入しにくい窓を選んだりしますよね。クラウド上のインフラ（サーバーやデータベースなど）をコードで作る「Terraform」や「CloudFormation」の世界でも、まったく同じことが言えます。
今回は、コードを書いた段階で「おっと、ここには泥棒が入れる隙があるよ！」と自動で教えてくれるセキュリティの相棒、tfsecやCheckovを使った静的解析パイプラインの作り方を、身近な例えを交えながら優しく解説していきますね。一歩ずつ、一緒に学んでいきましょう！
—
1. なぜ「デプロイ前のコードチェック（静的解析）」が重要なのか？
皆さんは、家を建てた「あと」になってから、「あ、玄関の鍵が壊れやすい安物だった！」とか「2階の窓に鍵がかかってなかった！」と気づいたとしたら、どう思いますか？ 一度建ててしまった家を直すのは、壁を壊したり大工事になったりして、すごく大変でお金もかかりますよね。
クラウドの世界でもこれと全く同じことが起きます。
TerraformやCloudFormationを使って、AWSなどのクラウド上にサーバーやデータベースを作った「あと」で、「あれ？データベースのデータが世界中に丸見えになってる！」と気づいたときには、すでにサイバー攻撃者にデータを盗まれているかもしれません。
そこで登場するのが、静的解析ツール（tfsecやCheckov）です。
これらは、いわば「プロの防犯診断士」のような存在です。実際に家（インフラ）を建てる前の「設計図（コード）」の段階で、「ここをこう直した方がいいよ」と優しく、かつ厳しく教えてくれます。
—
2. 攻撃者はどこを狙っているのか？（よくある設定ミス）
サイバー攻撃者は、スーパーマンのような超高度なハッキング技術だけでシステムを壊すわけではありません。実は、私たちがやりがちな「ちょっとした設定のうっかりミス」をスキャンして、そこからスルスルと侵入してきます。
よくある代表的なミスは次のようなものです。
- 家の玄関のドアが全開（S3バケットの公開設定）:
誰でも自由に中身を見たり書き換えたりできる状態でファイルを保存してしまうミス。
- 合鍵がマットの下に置いてある（秘密情報のハードコード）:
パスワードや暗号化の鍵（ここで言う共通鍵や公開鍵のペアなど）を、そのままコードに書き込んでしまうミス。
こうした「うっかり」を人間の目だけで何千行ものコードから見つけるのは、砂漠で針を探すようなものです。だからこそ、機械の力（静的解析ツール）を借りる必要があるんですね。
—
3. 自動チェックツール tfsec を実際に動かしてみよう！
それでは、実際にTerraformのコードをチェックする仕組みを覗いてみましょう。
例えば、以下のような「誰でも中身を見れてしまう危険なデータベース（Amazon RDS）」のコードがあったとします。
# 【危険な例】セキュリティ設定が甘いRDS（データベース）のコード
resource "aws_db_instance" "example" {
identifier = "my-database"
engine = "mysql"
instance_class = "db.t3.micro"
# あああ！データベースがインターネット全体に公開されてしまっています！
publicly_accessible = true
# 暗号化の設定が抜けています！
storage_encrypted = false
}このコードをそのままクラウドにデプロイしてしまうと、世界中の誰からでもアクセスできる危険なデータベースが出来上がってしまいます。
ここで、静的解析ツールである tfsec をこのコードに対して実行してみましょう。ターミナル（黒い画面）で次のようにコマンドを打ちます（※あらかじめツールがインストールされている前提です）。
tfsec .すると、tfsec は一瞬でコードを読み取り、次のようなアラートを出してくれます。
[AWS005][HIGH] Resource 'aws_db_instance.example' is publicly accessible.
[AWS014][MEDIUM] Resource 'aws_db_instance.example' storage is not encrypted.「おっと！データベースが公開されていますよ」「ストレージが暗号化されていませんよ」と、まるで頼もしいお医者さんのようにピンポイントで教えてくれるのです。
—
4. パイプラインに組み込んで「自動で防犯チェック」をする
手動で毎回チェックするのも面倒ですし、人間はうっかり忘れてしまう生き物です。だからこそ、GitHubなどのソースコード管理ツールにコードを保存（プッシュ）したタイミングで、自動的にこのチェックが走る仕組み（CI/CDパイプライン）を作りましょう。
以下は、GitHub Actionsを使って「コードが修正されるたびに、自動で tfsec と Checkov にチェックしてもらう」設定ファイルのサンプルです。
# .github/workflows/security-scan.yml
name: Infrastructure Security Scan
# コードがGitHubに送られた（push/pull_request）時に自動で動き出します
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
jobs:
ia-security-check:
runs-on: ubuntu-latest
steps:
# 1. まずは自分の書いたコードを読み込みます
- name: Checkout code
uses: actions/checkout@v4
# 2. tfsecを使ってTerraformのコードをスキャンします
- name: Run tfsec
uses: aquasecurity/tfsec-action@v1.0.3
# 3. Checkovを使って、CloudFormationやTerraformのポリシー違反をチェックします
- name: Run Checkov
uses: bridgecrewio/checkov-action@master
with:
framework: terraform # チェック対象のフレームワークを指定この設定ファイルをプロジェクトの .github/workflows/ ディレクトリに置いておくだけで、開発者がうっかりセキュリティの甘いコードを書いたときに、GitHub上で「エラー！このままではマージ（合体）できません！」と自動でストップをかけてくれるようになります。
—
5. まとめ：安全なインフラは「コードの段階」から作ろう
今回は、TerraformやCloudFormationなどのInfrastructure as Codeにおける静的解析（tfsecやCheckov）について解説しました。
- インフラのセキュリティは、家を建てた「あと」ではなく、「設計図（コード）を書いている段階」で守るのが一番コスパが良く確実であること。
- 人間の目だけに頼らず、
tfsecやCheckovといった自動ツールに「防犯診断」をしてもらう仕組み（パイプライン）を作ること。
これらを意識するだけで、あなたの作るシステムは劇的に安全になります。
「セキュリティ」と聞くと難しく身構えてしまうかもしれませんが、一歩ずつ、こうした便利なツールを味方につけていけば大丈夫です。一緒に安全で快適なクラウド環境を作っていきましょう！
コメント