セキュリティ設定の不備（A05:2021）をIaCで封じ込めろ：現場の「デフォルト」が一番の弱点だ
現場で数多のインシデントを見てきたが、皮肉なことに、最新のゼロデイ脆弱性よりも「デフォルト設定のまま放置されたクラウド環境」の方が、攻撃者にとってはるかに美味しい果実だ。
OWASP Top 10の「A05:2021-Security Misconfiguration（セキュリティ設定の不備）」は、単なる設定ミスではない。これは、お前の構築した堅牢なアプリを、裏口から丸裸にするための招待状なんだ。今日は、この「設定の甘さ」をコードで自動的に叩き潰すための、実戦的な防衛術を伝授する。
—
1. なぜ「デフォルト」が最大の攻撃対象になるのか
攻撃者は、ツールを使ってインターネット上のクラウドストレージ（S3バケットなど）をスキャンしている。彼らは「設定ミス」という宝探しをしているわけだ。
例えば、開発中の検証環境で「とりあえず動くように」と設定したIAMロールや、パブリック公開されたS3バケット。これらは一瞬でbotネットに発見され、バックドアを仕込まれる。
攻撃手法のリアル（PoCの視点）
攻撃者は、aws s3 ls --region us-east-1 のようなコマンドをIPレンジ全域に投げ、権限が *（All Allow）になっているリソースを血眼で探している。一度見つかれば、そこから認証情報（AWS_ACCESS_KEY_ID等）を抜き取り、お前のAWS環境全体が乗っ取られるのは時間の問題だ。
これを防ぐ唯一の手段は、人間が手作業で設定を確認するのをやめ、「コードによる強制（Policy as Code）」を導入することだ。
—
2. IaCによる防御：Terraformで設定ミスを「ビルド前」に弾く
運用でカバーするのは限界がある。Terraformのコードを書く段階で、セキュリティガードレールを敷くのがプロの仕事だ。
以下のサンプルは、S3バケットを定義する際に「パブリックアクセスを絶対に許さない」ための設定例だ。
# セキュアなS3バケット定義（Terraform）
resource "aws_s3_bucket" "secure_bucket" {
bucket = "my-company-sensitive-data"
}
# パブリックアクセスを全遮断するリソースを追加（必須）
resource "aws_s3_bucket_public_access_block" "block_public" {
bucket = aws_s3_bucket.secure_bucket.id
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}
# 暗号化もデフォルトで強制
resource "aws_s3_bucket_server_side_encryption_configuration" "encryption" {
bucket = aws_s3_bucket.secure_bucket.id
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "AES256" # 共通鍵暗号による自動暗号化
}
}
}このように、リソース定義とセットで「ブロック設定」を記述することで、万が一誰かがコンソールでポチポチ設定を変えようとしても、terraform apply を実行するたびに設定が正当な状態に強制修正される。
—
3. アプリ層でのセキュリティ：認証と暗号化の使い分け
クラウド側の設定だけではなく、アプリケーション側で「暗号理論」を正しく実装することも重要だ。よくあるミスが、すべての暗号化をRSA（公開鍵暗号）で行おうとすることだ。RSAは遅い。
実務的な使い分けルール
- 共通鍵暗号（AES-256-GCM）: 大量のデータ（DB保存、ファイル暗号化）の保護に使う。
- 公開鍵暗号（ECC / RSA）: 共通鍵の交換やデジタル署名に使う。
以下は、Pythonで安全にデータを暗号化する実装例だ。鍵管理（KMS）と組み合わせるのがベストだが、まずはコードレベルでのセキュアな設計を理解してほしい。
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os
# 1. 256ビットの鍵を生成（本来はAWS KMS等の鍵管理サービスから取得すること）
key = AESGCM.generate_key(bit_length=256)
aesgcm = AESGCM(key)
# 2. 認証付き暗号（GCMモード）を使用
# データの改ざん検知が可能なため、Webアプリのセッション管理等で必須
data = b"confidential-data"
nonce = os.urandom(12) # 毎回ランダムなナンス（初期化ベクトル）を生成
ciphertext = aesgcm.encrypt(nonce, data, None)
print(f"暗号化済みデータ: {ciphertext.hex()}")—
4. 最後に：エンジニアが守るべき鉄則
セキュリティ設定の不備は、「悪意」ではなく「怠慢」から生まれる。
1. デフォルトを信じるな: クラウドのデフォルトは「利便性優先」であり「セキュリティ優先」ではない。
2. IaCを正義とせよ: 手動設定は「記録が残らない」ため、インシデント時の追跡が不可能になる。すべての設定はGitにコミットし、CI/CDで tfsec や checkov などの静的解析ツールを回せ。
3. 最小権限の原則: IAMロールは * を使わず、必要なアクションだけをリストアップしろ。
セキュリティは「完成したら終わり」ではない。今日書いたコードが、明日には古い設定になっているかもしれない。常に疑い、自動化し、監視し続けること。それが我々エンジニアの誇りだ。
次回の記事では、このIaC環境に対して、実際にGitHub Actionsでどのタイミングでセキュリティスキャンを走らせるべきか、具体的なパイプライン設定を解説する。それまで、お前のリポジトリの terraform ファイルを見直しておくように。
コメント