こんにちは！インフラやセキュリティの世界へようこそ。これからサーバーやクラウドを使ったシステム作りを始めていくと、「IaC（Infrastructure as Code：アイ・エー・シー）」という言葉を耳にする機会がグッと増えてくると思います。
TerraformやCloudFormationといったツールを使って、これまで手作業でカチカチと設定していたサーバーやネットワークを、すべて「プログラム（コード）」として管理する便利な仕組みですね。
でも、このIaC、便利でスピード感がある一方で、「うっかりミスで鍵のついた扉を全開にしてしまうリスク」と常に隣り合わせなんです。今回は、新人のエンジニアの皆さんに向けて、クラウドの「IAM（Identity and Access Management）」というアクセス権の仕組みと、それをデプロイ前に自動でチェックする方法について、身近な例えを交えながら優しく紐解いていきたいと思います。一歩ずつ、安心して学んでいきましょう！
—
1. 家の鍵に例える「IAM（権限）」とIaCの怖さ
まずは、クラウドの安全を守る「IAM」について考えてみましょう。
皆さんが暮らす家を思い浮かべてみてください。玄関にはしっかりとした鍵がかかっていて、家族だけが入れるようになっていますよね。さらに、金庫には通帳や大切な実印が入っていて、限られた人しか開けられないようになっています。
クラウドの世界でも全く同じです。
- クラウドの環境 ＝ あなたの大きなお家
- サーバーやデータベース ＝ 家の中の大切な部屋や金庫
- IAM（権限設定） ＝ 誰がどの部屋に入っていいか決める「合鍵」の管理
「このプログラム（アプリ）には、写真置き場（ストレージ）を見る権限だけを渡そう」「データベースを書き換える権限は、特定の管理システムだけにしよう」と、必要最低限の鍵を渡すのがセキュリティの基本です。これをセキュリティ用語で「最小権限の原則」と呼びます。
泥棒は「開けっ放しの窓」を見逃さない
ここで、TerraformやCloudFormationといったIaCの出番です。皆さんは「こんなシステムを作りたい！」とコードを書きます。
# 【注意】これはやってはいけない「全部お任せ」の危険なコード例です
resource "aws_iam_policy" "dangerous_policy" {
name = "AllAccessPolicy"
# すべてのサービスに対して、すべての操作を許可してしまう（＝合鍵を全部渡す）
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Action = "*"
Effect = "Allow"
Resource = "*"
}
]
})
}上記のコード、何が問題かわかりますでしょうか？
Action: "*" と Resource: "*" は、いわば「クラウド上のすべての部屋に入り放題、すべての金庫を開け放題のマスターキー」を、そのプログラムに渡してしまう設定なんです。
もし、このコードで構築されたアプリにほんの小さなセキュリティの隙（脆弱性）が見つかってしまったらどうなるでしょう？ 悪い人（攻撃者）は、そのマスターキーを奪い取り、クラウド内にあるすべてのデータを自由にいじったり、勝手に高額なサーバーをマイニング（仮想通貨の採掘）用に立ち上げたりしてしまいます。家を建てた瞬間に、玄関の鍵をわざわざ外し、さらに「ご自由にお入りください」と貼り紙をしているようなものなんです。恐ろしいですよね。
—
2. 人間の目はあてにならない？静的解析ツールの導入
「じゃあ、コードを書くときに気を付ければいいんだね！」と思いますよね。その通りなのですが、人間は誰しもうっかりミスをします。深夜の作業で疲れていたり、急ぎのリリースだったりすると、ついテスト用の * （すべて許可）を消し忘れて本番環境にデプロイしてしまうことがあります。
そこで登場するのが、今回のテーマである「IaCの静的解析（セキュリティスキャン）」です。
これは、人間がコードを読んでチェックするのではなく、「プログラムをデプロイする前に、自動ロボットにコードを読ませて、危険な鍵の渡し方をしていないか厳しくチェックしてもらう仕組み」になります。
空港の保安検査場をイメージしてください。飛行機に乗る前に、カバンの中に危険物が入っていないか機械（X線検査）で自動的にチェックされますよね。あれと全く同じことを、クラウドのコードに対しても行うのです。
—
3. CI/CDパイプラインにセキュリティを組み込もう
この自動チェックを、開発のどのタイミングで行うのが一番効果的でしょうか？
それは、「GitHubなどにコードをプッシュした瞬間（CI/CDパイプライン）」です。
開発者がコードを書いて「よし、これでおしまい！」とリモートリポジトリに送ったタイミングで、自動的にセキュリティチェックのロボットが動き出します。もし先ほどのよからぬ Action: "*" が見つかったら、「おいおい、この設定は危ないからデプロイするのをストップ！」と、自動で赤信号を灯して止めてくれるのです。
実際に、オープンソースでよく使われている静的解析ツール Checkov（チェコフ） を使ったCI/CD（GitHub Actions）の設定例を見てみましょう。難しそうに見えますが、設定はとってもシンプルです。
# .github/workflows/security-scan.yml
name: IaC Security Scan
# 開発者がコードをGitHubに送った（pushした）時に自動で動き出します
on:
push:
branches: [ main ]
jobs:
trivy-or-checkov-scan:
runs-on: ubuntu-latest
steps:
# 1. まずはあなたの書いたコードを手元（仮想環境）に持ってくる
- name: Checkout Code
uses: actions/checkout@v4
# 2. セキュリティチェックの専門ツール（Checkov）を動かす
- name: Run Checkov Security Scan
uses: bridgecrewio/checkov-action@master
with:
# Terraformのコードが置いてあるディレクトリを指定
directory: ./terraform/
# 検出されたセキュリティエラーでビルドを失敗させる（＝デプロイをブロックする）
framework: terraform
soft_fail: false # falseにすることで、危険なコードがあればここでストップさせますこの仕組みをパイプラインに入れておくだけで、「うっかり危険な権限設定をしてしまったコード」が、本番のクラウド環境にたどり着く前にガッチリとブロックされます。
—
4. 現場の知見：形骸化させないための泥臭い工夫
さて、ここまで聞くと「ツールを入れれば完璧だね！」と思われるかもしれませんが、現場の最前線にいる私たちからお伝えしたい「リアルな落とし穴」が一つあります。
それは、「厳しくしすぎると、開発現場から嫌われてルールが形骸化する」という問題です。
セキュリティをガチガチにしすぎて、ちょっとしたテスト用の設定や、どうしても一時的に広い権限が必要な場面でも「エラー！デプロイ禁止！」とロボットがすべてを跳ね返してしまうと、開発者たちはどうなるでしょうか？
「もう、このセキュリティチェックの仕組み、めんどくさいから無効化しちゃおうぜ…」と、裏技を探してルールをすり抜けようとする心理が働いてしまいます。これでは本末転倒ですよね。セキュリティと開発のスピードは、いわば「車のブレーキとアクセル」の関係です。
現場で実践しているアプローチ
1. 「例外」の管理を明確にする： どうしても一時的に広い権限が必要なファイルや行には、ツールの警告を無視するコメント（抑制コメント）を正当な理由とともに残せるようにします。例えば、Checkov なら #checkov:skip=CKV_AWS_111:一時的な検証のため例外的に許可 のような形でコード内に理由を明記させます。
2. 段階的に厳しくする： いきなり全てのルールを適用するのではなく、まずは「絶対にやってはいけない重大なミス（マスターキーの付与など）」だけをブロックするように設定し、チームが慣れてきたら少しずつチェックの目を厳しくしていきます。
—
まとめ：安全なクラウド生活の第一歩を踏み出そう
今回は、IaCにおけるIAM設定の静的解析と、CI/CDパイプラインへの統合についてお話ししました。
- IAMの設定は、お家の「合鍵の管理」と同じ。必要最小限の権限（最小権限の原則）を意識しよう。
- 人間のうっかりミスを防ぐために、デプロイ前に「静的解析ツール」で自動チェックさせよう。
- CI/CDパイプラインに組み込むことで、危ないコードが本番環境に行くのを未然に防ごう。
- 開発現場が息苦しくならないよう、ルールとうまく付き合う工夫を忘れずに。
セキュリティと聞くと、なんだか難しくて窮屈なものに感じてしまうかもしれませんが、本質は「自分たちの作ったシステムやデータを守り、安心して開発を楽しむためのセーフティネット」です。
ぜひ、皆さんのプロジェクトにも小さな一歩としてセキュリティスキャンの仕組みを取り入れてみてくださいね。応援しています！
コメント