Checkovでクラウドの脆弱性を未然に防ぐ：IaCセキュリティを「シフトレフト」する – ITFROMZERO

Table of Contents

「インフラの脆弱性」という悪夢

10件以上のプロジェクトのセキュリティ監査に直接携わって気づいた残酷な真実があります。それは、重大な脆弱性の多くはアプリケーションのコードではなく、インフラの設定にあるということです。ある時、500GBもの顧客の身分証画像が入ったS3バケットがパブリック設定になっているのを見て絶句したことがあります。また別のケースでは、KubernetesクラスターでPodがルート権限での実行を許可されており、ハッカーがノード全体を支配できる状態になっていました。

これらのミスは、Infrastructure as Code (IaC) の設定ファイルに起因することがほとんどです。TerraformやCloudFormationでインフラを管理している場合、たった一行のコードミスが、わずか数秒でクラウド上の何百ものリソースにエラーを増殖させてしまいます。

なぜデプロイ後にセキュリティスキャンを行うのが「手遅れ」なのか？

Gartnerによると、2025年までにクラウドセキュリティ事故の95%以上はユーザー側の設定ミスが原因になると予測されています。従来のプロセスは「コードを書く -> デプロイ -> ランタイムでスキャン」というものでしたが、これではコストがかさむだけでなく、スキャンを待つ間、システムがリスクにさらされ続けます。

IaCセキュリティが軽視される3つの大きな障壁：

リリースのプレッシャー： セキュリティよりも、まずは機能が動くことを優先してしまう。
デフォルト設定の罠： 多くのクラウドサービスは導入しやすさを優先し、デフォルト設定が比較的緩くなっている。
膨大な設定ファイル： Terraformファイルが2,000行を超えると、目視でのレビューは砂漠で針を探すようなものです。

デプロイ後にミスが見つかれば、ロールバック and 修正に多大な時間がかかります。最悪の場合、そのわずかな「隙」を突かれて、機密データが流出してしまうかもしれません。

IaCセキュリティにおける3つの一般的なアプローチ

現在、DevOpsチームは通常、以下の3つのいずれかの方法を選択しています。

手動レビュー： 丁寧ですが、時間がかかり、ヒューマンエラーが発生しやすい。
外部監査： コストが高く、四半期や年単位での実施が多いため、CI/CDのスピードに追いつけない。
静的解析 (Static Analysis)： これが最適な選択肢です。コードを書いた直後にファイルをスキャンし、リソースが作成される前にリスクを遮断します。

Checkov：DevOpsエンジニアの強力な味方

静的解析ツールの世界で、Checkovは「ゴールデンスタンダード」として定着しています。これは Bridgecrew（現在はPalo Alto Networks傘下）が開発したオープンソースツールで、Terraform、CloudFormation、KubernetesからDockerfile、Helmまで幅広くサポートしています。

Checkovは、CISベンチマークに基づいた1,000以上のセキュリティポリシーを保有しています。単にエラーを報告するだけでなく、違反しているコードの行を特定し、詳細な修正ガイドへのリンクまで提供してくれます。

30秒で完了するクイックインストール

pipを使って非常に素早くインストールできます。私はコミット前にローカルで素早くチェックするために、直接マシンにインストールしています。

pip install checkov

インストールを汚したくない場合は、Dockerが最もクリーンな解決策です：

docker pull bridgecrew/checkov
docker run -v /path/to/your/code:/tf bridgecrew/checkov -d /tf

実践1：Terraformのエラーをスキャンする

以下の main.tf ファイルを見てみましょう。一見普通に見えますが、「時限爆弾」が隠されています。

resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  
  # ディスクが暗号化されていない
  ebs_block_device {
    device_name = "/dev/sda1"
    volume_size = 20
  }
}

ディレクトリ内でスキャンコマンドを実行します：

checkov -d .

即座にCheckovは FAILED を報告し、エラーコード CKV_AWS_3 を表示します。これは、サーバーが攻撃を受けた際のデータを保護するために、EBSボリュームを暗号化する必要があるという警告です。

実践2：Kubernetesの設定をチェックする

Kubernetesにおいて、Checkovは権限昇格に関するミスに対して非常に敏感です。この pod.yaml をスキャンしてみましょう：

spec:
  containers:
  - name: nginx
    image: nginx
    securityContext:
      privileged: true # 非常に深刻なエラー

privileged: true フラグはコンテナがホストマシンのカーネルに深く干渉することを許可してしまうため、Checkovが警告を発します。このフラグを無効にするか、Pod Security Standardsを使用するよう求められます。

警告をスキップするコツ (Suppressing)

コスト削減のために開発環境でリスクを許容する場合（例：テスト用ディスクの暗号化が不要な場合など）があります。Checkovでパイプラインを中断させないようにするには、コードに直接コメントを追加します：

resource "aws_instance" "web_server" {
  # checkov:skip=CKV_AWS_3: サンドボックス環境のため一時的にスキップ
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

GitHub ActionsのパイプラインにCheckovを組み込む

真の安心を得るためには、CheckovをCI/CDに統合すべきです。Highレベルの脆弱性が検出された場合、パイプラインを自動的に停止し、メインブランチへのマージを許可しないように設定できます。

name: Checkov Security Scan
on: [push, pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: .
          framework: terraform
          soft_fail: false # エラーがある場合はパイプラインを中断する

Lời kết

インフラのセキュリティ対策は、一度やれば終わりというものではありません。コードを書く際の一つの「習慣」です。Checkovは、システムを洗練された攻撃から100%守るわけではありませんが、よくある「うっかりミス」の90%を確実に排除してくれます。

私からのアドバイスはこうです：AWSから警告メールが届いたり、データがネットで販売されているのを見つけるまで待たないでください。今すぐCheckovを導入しましょう。自分のリポジトリにどれほどの「隙」があったのか、驚くことになるはずです。