こんにちは！インフラやセキュリティの世界へようこそ。
初めてクラウドを触る時、「データベース（DB）をどうやって守ればいいんだろう？」と不安になりますよね。Amazon RDSやGoogle Cloud SQLといったマネージドデータベースは非常に便利ですが、設定を一つ間違えると、世界中の悪意あるボットネットから丸見えになってしまいます。
今回は、新人のIT担当者や開発者の皆さんが「これさえやっておけば安心！」と言える状態を作れるよう、身近な防犯の例えを交えながら、データベースの「パブリックアクセス無効化」と「保存時暗号化」について一緒に紐解いていきましょう。一歩ずつ、丁寧に解説していきますね！
—
1. 家の鍵に例える「パブリックアクセス無効化」の必要性
まずは、データベースがインターネットに露出している状態をイメージしてみましょう。
皆さんが住んでいる家に例えるなら、パブリックアクセスが有効なデータベースとは、「玄関の鍵が全開で、しかも大通りに面している状態」です。泥棒（攻撃者）が歩きながらドアノブをガチャガチャと回し、鍵が開いていたら中に侵入して、家の中の家宝（大切な顧客データ）を全部盗み見たり、めちゃくちゃに破壊したりできてしまいます。
インターネット上には、日々こうした「鍵の開いた家」を探し回る自動プログラム（スキャナー）がうようよと徘徊しています。マネージドデータベースを作る際、うっかり「パブリックアクセス：許可（Yes）」にしてしまうと、この危険な状態を自ら作り出してしまうのです。
攻撃者はどうやって侵入するのか？
攻撃者は、データベース専用のポート（MySQLなら 3306、PostgreSQLなら 5432 など）に向けて、自動で総当たり攻撃（ブルートフォース攻撃）を仕掛けます。もしパスワードが「Password123」のような簡単なものだったら、ものの数分で破られ、データベースの中身がすべてダークウェブに晒されてしまいます。
防御の基本：プライベートな空間に閉じ込めよう
これを防ぐための最初のステップが、「パブリックアクセスの無効化」です。
家を頑丈な塀と警備員つきのマンションの奥深く（プライベートサブネット）に引っ越しさせ、外の世界からは絶対に直接アクセスできないようにします。アプリケーションサーバー（Webサーバー）だけがDBと通信できるように道を通し、一般のインターネットからの侵入を物理的・ネットワーク的にシャットアウトするのです。
—
2. 金庫と鍵の仕組み「保存時暗号化（TDE / KMS）」の正体
さて、ネットワークの壁を突破してもし万が一、悪い人がデータベースの「ハードディスクそのもの」を盗み出したり、バックアップデータを不正にダウンロードできたとしたらどうなるでしょうか？
ここで登場するのが「保存時暗号化（Encryption at Rest）」です。
データベースの仕組みとしては、TDE（Transparent Data Encryption）や、クラウドの鍵管理サービスであるKMS（Key Management Service）を使って実現します。
これも身近な例えで考えてみましょう。
先ほどの家の中で、いくら玄関の鍵を閉めていても、窓ガラスを割られて侵入されたとします。泥棒は部屋の中にある「紙の台帳（暗号化されていないデータ）」をそのまま持って逃げることができますよね。
しかし、保存時暗号化を有効にしている状態とは、「家の中にあるすべての財宝が、専用の特殊な金庫にしまわれており、その金庫を開ける鍵は、信頼できる銀行の金庫（KMS）の奥深くに預けられている状態」です。
仮に泥棒がハードディスク（金庫の箱ごと）を盗み出したり、クラウドのストレージからデータを不正コピーしたとしても、中身はグチャグチャに暗号化された意味不明な文字列（暗号文）になっています。鍵を持っていないため、中身を読み解くことは絶対に不可能なのです。
—
3. 実践！AWS RDS / Google Cloud SQLの設定と監査
それでは、実際のクラウド環境でどのように設定・確認すればよいのか、具体的なコードや設定を見ていきましょう。難しく考えず、「こういう設定項目があるんだな」と眺めてみてくださいね。
① AWS RDS（MySQL/PostgreSQLなど）のTerraform設定例
インフラをコード（IaC）で管理する際、Terraformを使うと設定ミスを防ぐことができます。以下は、パブリックアクセスをオフにし、KMSで暗号化を有効にする典型的な設定サンプルです。
# AWS RDS データベースインスタンスの定義
resource "aws_db_instance" "secure_database" {
identifier = "my-production-db"
engine = "postgres"
engine_version = "15.4"
instance_class = "db.t4g.medium"
allocated_storage = 20
# 【重要】パブリックアクセスを完全に遮断（プライベートサブネットに配置）
publicly_accessible = false
# 【重要】保存時暗号化（Encryption at Rest）の有効化
storage_encrypted = true
# AWSが管理するデフォルトのKMSキー、または独自のカスタムKMSキーを指定
# kms_key_id = aws_kms_key.my_custom_key.arn
db_name = "appdb"
username = "dbadmin"
password = var.db_password # 機密情報は変数から渡す
# データベースが所属するサブネットグループ（プライベートを指定すること）
db_subnet_group_name = aws_db_subnet_group.private_subnet_group.name
# 誤削除を防ぐためのスナップショット保持や削除保護
skip_final_snapshot = false
final_snapshot_identifier = "my-production-db-final-snapshot"
deletion_protection = true
}② Google Cloud SQL（PostgreSQL）の設定例
GCPのCloud SQLでも考え方は全く同じです。インターネットからのアクセスを禁止し、独自の暗号化キー（CMEK）またはGoogle管理の鍵でデータを守ります。
# Google Cloud SQL インスタンスの定義
resource "google_sql_database_instance" "secure_sql_instance" {
name = "my-secure-sql-instance"
database_version = "POSTGRES_15"
region = "asia-northeast1"
settings {
tier = "db-custom-1-3840"
# 【重要】IP設定の調整
ip_configuration {
# パブリックIPを無効化し、プライベートIP（VPC内）のみ許可する
ipv4_enabled = false
private_network = google_compute_network.vpc_network.id
}
# バックアップや暗号化の設定
backup_configuration {
enabled = true
start_time = "04:00"
point_in_time_recovery_enabled = true
}
}
# 暗号化はデフォルトでGoogle管理の鍵で行われますが、
# より厳重に行う場合は Cloud KMS (encryption_key_name) を指定します。
}—
4. 設定したら終わりじゃない？定期的な「監査」の重要性
「よし、コード書いてデプロイしたから完璧だね！」……ちょっと待ってください。セキュリティの世界では、「作った当時は完璧でも、人の手によって後から穴が空く」ことが本当によくあります。
例えば、
- 「テストのために、ちょっとだけ一時的にパブリックアクセスを『有効』に変えて、そのまま戻し忘れた」
- 「新しいプロジェクトメンバーが、間違った設定でデータベースを追加してしまった」
こうしたヒューマンエラーや設定の綻びを検知するために、「監査（セキュリティチェック）」を定期的に行う仕組みが欠かせません。
AWSであれば AWS Config や Amazon Inspector、GCPであれば Security Command Center といったクラウド標準の監視ツールを有効にしておきましょう。「もしパブリックアクセスが有効なRDSが作られたら、即座にSlackに通知してアラートを飛ばす、あるいは自動で修正する」といったガードレール（防護壁）を張っておくことが、プロのインフラエンジニアの腕の見せ所です。
—
まとめ
今回は、マネージドデータベースを守るための基本中の基本である「パブリックアクセス無効化」と「保存時暗号化」について解説しました。
1. パブリックアクセス無効化: データベースの玄関の鍵を閉め、大通り（インターネット）に露出させない。プライベートな空間だけで通信させる。
2. 保存時暗号化（TDE / KMS）: 万が一データが盗まれても、中身が金庫に守られた暗号文になっているため解読されないようにする。
3. 監査と継続的監視: 人間はミスをする生き物だからこそ、ツールを使って設定のミスを自動で検知・防御する。
セキュリティと聞くと難しそうに感じるかもしれませんが、要は「泥棒が入ってこないように扉を閉め、万が一入られても開けられない金庫に入れておく」という、現実世界の防衛策と全く同じです。
一歩ずつ、安全なインフラ環境を一緒に作っていきましょう！それではまた次回の記事でお会いしましょう。
コメント