こんにちは！クラウドの普及に伴い、インフラの構築もコード（プログラム）で行う時代になりましたよね。「Infrastructure as Code（IaC）」、なんだか名前を聞くだけで難しそう…と思われるかもしれませんが、大丈夫です。一歩ずつ、身近な例えから紐解いていきましょう！
今日は、TerraformやCloudFormationといったIaCツールを使ってクラウドへ家を建てる（インフラをデプロイする）とき、「泥棒が入る隙がないか、建てる前に図面を徹底的にチェックする（静的解析）」という、現場ですごく大切なセキュリティの知恵についてお話しします。
—
1. なぜ「建てる前」の図面チェックが大事なの？防犯の例えで考えよう
皆さんがマイホームを建てると想像してください。
設計図の段階で「あ、ここ、表から丸見えの大きなガラス窓なのに、鍵がついてないや」「勝手口の横に、外からよじ登れそうな足場があるぞ」と気づけたら、家が完成する前に設計図を修正できますよね。
これがもし、家が完成して引っ越した（＝クラウドにシステムを本番公開した）あとだったらどうでしょう？
鍵を後から付け直すには、壁を壊したり、大工さんをもう一度呼んだりして、ものすごい時間とコストがかかります。最悪の場合、泥棒に入られてから「あ、鍵が甘かったんだ！」と気づくことになります。
クラウドのインフラも全く同じです。
Terraformなどのコード（設計図）を書いているときは、まだ何も実体のない「ただのテキストファイル」です。この設計図の段階で、うっかり「世界中の誰からでもアクセスできる設定（0.0.0.0/0）」にしてしまっていないかを自動でチェックする仕組み。それが、今回ご紹介する静的解析（Checkovなどのツールを使ったデプロイ前の脆弱性チェック）なんです。
—
2. 攻撃者はどこを狙っている？よくあるIaCの「うっかりミス」
実際の現場で、新人の開発者やインフラ担当者がやりがちな「うっかりミス」を攻撃者は容赦なく狙ってきます。
例えば、AWSのストレージサービスであるS3バケットを作るコードを書いたとします。
- うっかりミスその1： 「とりあえずテストだから、誰でも中身を見られるようにしちゃえ」と公開設定にしてしまう。
- うっかりミスその2： 大切なデータなのに、誰もが見られないようにする「鍵（暗号化）」をかけ忘れる。
攻撃者は、自動化されたプログラムを使って、インターネット上にぽんと公開された「鍵のかかっていないクラウドの金庫」を常に探しています。見つかったが最後、会社の機密情報や顧客データがごっそり盗まれてしまう……なんてインシデントが、世界中で後を絶ちません。
だからこそ、人間の目だけに頼るのではなく、「機械の目で厳しくチェックする仕組み」を開発の自動化パイプライン（CI/CD）に組み込む必要があるのです。
—
3. 実践！CI/CDに静（せいの）的解析ツール「Checkov」を組み込もう
それでは、実際にTerraformのコードをチェックするツール「Checkov（チェコブ）」を例に、どのように動くのか見ていきましょう。
例えば、以下のようなTerraformのコード（設計図）があったとします。これは「S3バケットを作る」コードですが、セキュリティ的には「NG（バッドプラクティス）」な書き方を含んでいます。
# 【危ない設計図の例】 セキュリティ対策が抜けているTerraformコード
resource "aws_s3_bucket" "example_bucket" {
bucket = "my-company-secret-data-bucket"
# ここにパブリックアクセス（誰でも見られる設定）を制限する記述がない！
# さらに、保存するデータの暗号化設定も抜けている！
}このコードをそのままクラウドにデプロイしてしまうと、セキュリティ上の穴だらけになってしまいます。
そこで、CI/CDパイプライン（GitHub Actionsなど）の中で、デプロイが実行される前にCheckovという静的解析ツールを走らせます。
実際のGitHub Actionsの設定ファイル（.github/workflows/security-check.yml）の例を見てみましょう。
# GitHub ActionsでTerraformのセキュリティチェックを自動化する設定
name: IaC Security Check
on:
pull_request:
branches: [ main ] # mainブランチへ取り込む前のプルリクエスト時に実行します
jobs:
checkov:
runs-on: ubuntu-latest
steps:
- name: ソースコードをチェックアウト
uses: actions/checkout@v3
- name: Python環境のセットアップ
uses: actions/setup-python@v4
with:
python-version: '3.10'
- name: Checkovのインストール
run: pip install checkov
- name: Terraformコードに対してCheckovを実行
run: |
checkov -d .
# ここでディレクトリ（-d .）内のすべてのIaCファイルをスキャンし、
# セキュリティ上の問題がないか自動で採点・チェックしますこのワークフローを仕込んでおくと、開発者が「この設計図で家を建てたいです（プルリクエスト）」と申請した瞬間に、裏側でCheckovが自動的に設計図を隅々まで読み込みます。
もし先ほどのような危ないコードが含まれていた場合、Checkovは以下のように怒って（エラーを出して）くれます。
[1] CKV_AWS_19: "Ensure all data stored in the S3 bucket is encrypted" (S3のデータが暗号化されていません)
[2] CKV_AWS_20: "S3 Bucket has a public ACL. Untrusted users can access this." (S3バケットが誰でもアクセス可能な状態です)このエラーが出ると、「セキュリティのチェックをクリアしていないので、まだ家を建てることはできません！」と自動的にストップがかかります。これで、うっかりミスのまま本番環境にデプロイされる事故を防ぐことができるというわけです。
—
4. 安全な設計図に直してみよう
怒られたら、設計図を正しい安全な形に修正します。先ほどのTerraformコードに、暗号化とパブリックアクセス禁止の設定を追加してみましょう。
# 【安全な設計図の例】 セキュリティ対策を盛り込んだTerraformコード
resource "aws_s3_bucket" "example_bucket" {
bucket = "my-company-secret-data-bucket"
}
# パブリックアクセスをブロックする設定を追加
resource "aws_s3_bucket_public_access_block" "example_block" {
bucket = aws_s3_bucket.example_bucket.id
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}
# サーバー側の暗号化（AES256）を有効化する設定を追加
resource "aws_s3_bucket_server_side_encryption_by_default" "example_encryption" {
bucket = aws_s3_bucket.example_bucket.id
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "AES256"
}
}
}ここまで直してからもう一度Checkovを走らせると、「エラーなし！合格です！」とパスするため、安心してデプロイを進めることができます。
—
5. まとめ：安全な自動化で、開発のスピードと安心を両立しよう
「セキュリティチェックを厳しくすると、開発のスピードが落ちるのでは？」と心配になるかもしれません。でも、それは逆なんです。
家を建て直す大工事になる前に、設計図の紙の上でパッと修正できれば、修正はほんの数分で終わりますよね。IaCの静的解析（Checkovなど）をCI/CDパイプラインに組み込むことは、「開発のスピードを落とさずに、むしろ人間のうっかりミスを自動でカバーして守ってくれる心強い相棒」をチームに迎えるようなものです。
セキュリティに初めて触れる方も、まずはご自身の書いているTerraformやCloudFormationのコードに、こうしたチェックツールを導入することから始めてみませんか？
一歩ずつ、安全で強いインフラストラクチャを作っていきましょう！
コメント