なぜ「RDSをインターネットに晒す」ことが、あなたのキャリアを終わらせるのか
現場で数々のインシデントを見てきたが、未だに「開発の利便性」を理由にRDSをパブリック公開し、セキュリティグループでIP制限をかけて安心しているエンジニアがいる。ハッキリ言おう。それは玄関の鍵を開けたまま、チェーンロックだけかけて「泥棒は入らないはずだ」と信じ込んでいるのと同じだ。
攻撃者は、あなたが設定したIP制限の隙間を縫うように、クラウド環境のメタデータサービスや周辺の踏み台サーバーを経由して侵入してくる。今回は、データベースという「組織の心臓部」をどう守り抜くか、実務レベルの防衛術を叩き込む。
—
1. データベース防御の鉄則：ネットワークと暗号化の二段構え
データベースを守るには「ネットワークの隔離」と「データの暗号化」の二つが不可欠だ。
ネットワーク：パブリックアクセス無効化は「絶対」
クラウド上のDB（RDSやCloud SQL）をパブリックアクセス可能にする理由は、現代のアーキテクチャでは存在しない。VPC内に閉じ込め、プライベートサブネットに配置する。接続が必要なら、Bastionホスト（踏み台）を経由するか、AWS Systems Manager Session Managerのような「鍵管理不要のトンネル」を利用すべきだ。
暗号化：AES-256で「ゴミ」にする
保存時暗号化（TDE/KMS）は、物理ストレージが盗難に遭った際や、バックアップデータが漏洩した際の「最後の砦」だ。暗号化されていれば、データが流出してもただのバイナリの羅列（ゴミ）に過ぎない。
—
2. 【コピペで防ぐ】実務で使える設定とコード例
まずは、Terraform等でインフラを定義する際の「セキュアな設定」の勘所だ。
AWS RDS (Terraform設定例)
resource "aws_db_instance" "secure_db" {
# パブリックアクセスを明示的に拒否
publicly_accessible = false
# 保存時暗号化を有効化（KMSキーを指定）
storage_encrypted = true
kms_key_id = aws_kms_key.db_key.arn
# IAM認証の有効化（パスワード流出リスクの低減）
iam_database_authentication_enabled = true
# VPC内への限定
vpc_security_group_ids = [aws_security_group.db_sg.id]
db_subnet_group_name = aws_db_subnet_group.private.name
}PythonでDB接続をIAM認証で行う（RDS用）
パスワードをコードに直書きするのは論外だ。IAMロールを利用して短命な認証トークンを取得する。
import boto3
def get_db_auth_token(hostname, port, db_user):
# RDSへの接続用認証トークンを生成（有効期限は15分）
client = boto3.client('rds')
token = client.generate_db_auth_token(
DBHostname=hostname,
Port=port,
DBUsername=db_user
)
return token
# このトークンをDB接続時のパスワードとして利用する
# これにより、DBのパスワードを環境変数や設定ファイルに書く必要がなくなる—
3. なぜ「公開」が致命的なリスクを生むのか：攻撃者の視点
もし君がDBをパブリック公開し、セキュリティグループのIP制限のみで守っているなら、攻撃者は以下のように動く。
1. ポートスキャン: 3306や5432が世界中に公開されていることを検知。
2. ブルートフォース: 管理者のパスワードを推測攻撃する。
3. 脆弱性の突撃: 特定のバージョンのMySQL/PostgreSQLに公開されている既知の脆弱性（CVE）を突き、権限昇格を狙う。
特に怖いのは、設定ミスによる意図しない公開だ。CloudWatchアラームで「DBインスタンスのパブリックフラグが変更されたら即時通知」を設定し、GitHubにTerraformファイルが誤ってプッシュされていないか、git-secrets等で常に監視する体制が必要だ。
—
4. セキュリティチーフからの「最後の警告」
技術スタックがいかに進化しても、攻撃手法の根っこにあるのは常に「人間の不注意」だ。
- 監査: AWS CloudTrailやGCP Cloud Audit Logsを有効にし、誰がいつDBの設定を変えたか、誰が接続を試みたかを常にログへ吐き出せ。
- 暗号化の基本: 共通鍵暗号（AES-256）は非常に高速で強固だ。ストレージ暗号化はパフォーマンスへの影響も軽微なので、迷わず全インスタンスで有効化すること。
「面倒だから」という言葉は、インシデント発生時の始末書の書き出しと同じだ。 今日紹介した設定は、明日からチーム全体で「デフォルトルール」として強制してほしい。セキュリティは足し算ではなく、掛け算だ。一つでも「適当」な部分があれば、全体のリスクはゼロに等しくなる。
君たちの手で、強固なインフラを作り上げてくれ。健闘を祈る。
コメント