「設定ミスは、家の窓を開けっ放しにするのと同じ」——IaCセキュリティ入門
こんにちは。普段は企業の防御壁を強固にしたり、時には「穴」を見つけて塞ぐ仕事をしています。
エンジニアとしてコードを書いていると、「動けば正義」と考えがちですよね。特に最近は、クラウドの設定をプログラムのように書ける「Infrastructure as Code（IaC）」が主流です。でも、ちょっと想像してみてください。あなたが頑張って建てた「クラウドの家」の窓が、実は全開になっていたら？
今日は、TerraformのようなIaCコードを「デプロイする前」にチェックして、泥棒に目をつけられる前に防ぐ方法を、一緒に紐解いていきましょう。
—
なぜ「コード」でセキュリティを語るのか？
皆さんが普段書いている main.tf（Terraformの設定ファイルなど）は、いわば「家の設計図」です。「ここに金庫を置く」「ここを玄関にする」といった指示書が、そのままクラウド上のインフラに反映されます。
もし、この設計図に「誰でも入れる勝手口を作る」という一行が混ざっていたら、クラウド上にそれがそのまま出来上がってしまいます。
- 手動での確認： 「設定画面を見ながらポチポチ確認する」のは、泥棒が入った後に鍵が空いていたことに気づくようなもの。
- IaCスキャン： 「設計図を描いている最中に、警察官がやってきて『その窓、鍵がかかってないですよ』と教えてくれる」仕組みです。
これが今回お話しする「IaCセキュリティスキャン」の正体です。
—
典型的な「やらかし」：S3バケットの公開設定
クラウドの世界で一番多い「やらかし」の一つが、S3バケット（データを保存する倉庫）の公開設定ミスです。本来、社外秘のデータが入っている倉庫の扉に「誰でも入れます」と看板を出してしまうようなものですね。
例えば、Terraformでこんなコードを書いてしまったとします。
# 悪い例：誰でもアクセス可能なバケットを作ってしまう
resource "aws_s3_bucket" "my_private_data" {
bucket = "my-secret-bucket"
# これが「誰でも読める」という設定になってしまう可能性がある
acl = "public-read"
}この acl = "public-read" という記述。これが書かれていることに気づかず「Apply（反映）」してしまうと、世界中からあなたのデータが見えてしまいます。
—
「デプロイ前」に自動で防ぐ魔法のツール
これを防ぐために、tfsec や tflint といった「静的解析ツール」を導入しましょう。これらは、コードを書き終えてデプロイボタンを押す前に、設計図を自動でチェックしてくれます。
導入のステップ
1. インストール： Macなら brew install tfsec などで簡単に入ります。
2. 実行： ターミナルで tfsec . と打つだけです。
もし先ほどのコードをスキャンすると、ツールはこう教えてくれます。
> 「警告：バケットがパブリックに設定されています。これは推奨されません。」
これで、デプロイする前に「あ、窓を開けっ放しにするところだった！」と気づけるわけです。
—
セキュリティの「一歩」を踏み出すために
「セキュリティを厳しくすると、開発が遅くなるんじゃない？」と心配する声が聞こえてきそうです。でも、逆です。後から直すほうが、何倍もコストがかかります。
家を建て終わってから「壁を壊して窓を埋める」のと、設計図の段階で「窓をなくす」の、どちらが簡単で安上がりでしょうか？
今日からできる「守りの姿勢」
- エディタの拡張機能を活用： VS Codeを使っているなら、IaCのセキュリティチェックができるプラグインを入れてみてください。保存するたびに「そこ危ないよ！」と波線で教えてくれます。
- CI/CDパイプラインに組み込む： GitHub Actionsなどを使っているなら、テスト工程に
tfsecを組み込みましょう。セキュリティテストが通らないコードは、そもそもリリースできない仕組みを作るのが、真のプロのやり方です。
—
最後に
セキュリティは、誰か特定の専門家がやる魔法ではありません。皆さんが書くその一行、その設定一つ一つが、お客様のデータを守る「鍵」になります。
最初は「難しいな」「面倒だな」と感じるかもしれません。でも、一つずつ、一つずつです。まずは、今書いているコードに「本当にこの扉、開けっ放しにしていいんだっけ？」と問いかけることから始めてみませんか？
その小さな「疑い」こそが、最強のセキュリティ対策への第一歩ですよ。また次回、もっと深い技術の深淵でお会いしましょう！
コメント