DB アクセス経路 - SSO + 踏み台経由の安全な DB アクセス
SSO から踏み台（Bastion）経由で DB に安全にアクセスするパターン。直接クレデンシャルでの DB 接続の危険性、AWS SSM Session Manager / Azure Bastion / GCP IAP を使ったアクセス経路、IAM 認証による DB 接続、監査ログの取得。
概念図
実例
直接クレデンシャルによる危険な DB 接続
bash
# 危険: DB パスワードを直接環境変数に設定して接続
export PGPASSWORD="SuperSecret123"
psql -h prod-db.example.com -U admin -d production
# パスワードがシェル履歴・プロセス一覧・ログに残るSSM Session Manager でのポートフォワード接続
bash
# 安全: SSM Session Manager 経由のポートフォワード
aws ssm start-session \
--target i-0123456789abcdef0 \
--document-name AWS-StartPortForwardingSessionToRemoteHost \
--parameters host="prod-db.cluster-xxx.ap-northeast-1.rds.amazonaws.com",portNumber="5432",localPortNumber="15432"
# localhost:15432 経由で RDS に接続（SSH 不要・22 番ポート不要）
psql -h localhost -p 15432 -U app_user -d productionRDS IAM 認証トークンによるパスワードレス接続
bash
# RDS IAM 認証によるパスワードレス接続
TOKEN=$(aws rds generate-db-auth-token \
--hostname prod-db.cluster-xxx.ap-northeast-1.rds.amazonaws.com \
--port 5432 \
--username iam_user)
PGSSLMODE=verify-full psql \
"host=prod-db.cluster-xxx.ap-northeast-1.rds.amazonaws.com \
port=5432 dbname=production user=iam_user password=$TOKEN"直接クレデンシャル接続の危険性
開発者や運用者が DB パスワードを直接使って本番データベースに接続する運用は、以下の理由で極めて危険である。
| リスク | 詳細 | 実際の事故パターン |
|---|---|---|
| パスワードの共有・拡散 | チーム内で同一パスワードを Slack / メモ / Wiki で共有 | 退職者がパスワードを知ったまま。変更されず数年間有効 |
| シェル履歴への残存 | PGPASSWORD=xxx psql ... が .bash_history に残る |
端末紛失時にシェル履歴からパスワード漏洩 |
| ネットワーク経路の問題 | DB ポート（3306/5432）を VPN 越しに直接公開 | VPN クレデンシャル漏洩 → DB に直接到達される |
| 監査証跡の欠如 | 共有アカウントのため「誰が」「何をしたか」を特定不可 | インシデント調査時に犯人特定ができない |
| ローテーション困難 | 全員がパスワードを知っているため変更時の影響範囲が大きい | パスワード変更のたびにアプリ・スクリプト・手順書を全更新 |
目指すべき姿: 「DB パスワードを誰も知らない」状態。
個人が直接パスワードを扱わず、SSO 認証 → 踏み台 → IAM 認証トークンの経路でアクセスする。
安全な DB アクセス経路: SSO → 踏み台 → DB
3 大クラウドはそれぞれ踏み台（Bastion）サービスを提供しており、SSH ポートを開けずにプライベートサブネットの DB に到達できる。
アクセス経路は以下の通り。
標準アクセスフロー:
- 開発者が IdP（Entra ID / Okta / Google Workspace）で SSO 認証 + MFA
- クラウドの踏み台サービスを経由してプライベートサブネットに接続
- IAM 認証トークンまたはシークレットマネージャー経由でパスワードを取得し DB に接続
- 全操作が監査ログに記録される
| 比較項目 | AWS SSM Session Manager | Azure Bastion | GCP IAP（Identity-Aware Proxy） |
|---|---|---|---|
| 接続方式 | SSM エージェント経由（ポート不要） | Azure Portal / ネイティブクライアント経由 | IAP トンネル経由（gcloud compute ssh） |
| SSH ポート | 不要（22 番ポートを開けない） | 不要（443 のみ） | 不要（IAP が中継） |
| 前提条件 | EC2 に SSM エージェント + IAM ロール | Azure Bastion サブネット + NSG | IAP API 有効化 + ファイアウォールルール |
| ポートフォワード | AWS-StartPortForwardingSessionToRemoteHost |
Azure CLI az network bastion tunnel |
gcloud compute start-iap-tunnel |
| セッション記録 | Session Manager ログ → S3 / CloudWatch | Azure Bastion 診断ログ | Cloud Audit Logs |
| 料金 | 無料（SSM は追加料金なし） | 有料（Bastion ホスト課金） | 無料（IAP 自体は無料。VM は別途） |
| 追加機能 | Run Command によるリモートコマンド実行 | ファイルアップロード / ダウンロード | TCP フォワーディング対応 |
共通の設計原則:
- DB は必ずプライベートサブネットに配置し、パブリック IP を付与しない
- 踏み台サービスへのアクセスを SSO + MFA で認証し、IP 制限も併用
- ポートフォワードで localhost 経由接続し、DB クライアントから直接プライベート IP に到達させない
- 全セッションを監査ログに記録し、SIEM に転送
IAM 認証による DB 接続
パスワードの代わりに IAM 認証トークンを使って DB に接続する方式。
トークンは一時的（15 分程度）で自動失効するため、パスワード漏洩リスクを根本から排除できる。
| 比較項目 | AWS RDS IAM Auth | Azure AD Auth (Azure SQL / PostgreSQL) | GCP Cloud SQL IAM Auth |
|---|---|---|---|
| 対応 DB | MySQL、PostgreSQL、MariaDB | Azure SQL Database、Azure Database for PostgreSQL | Cloud SQL for MySQL、Cloud SQL for PostgreSQL |
| 認証方式 | IAM ロール/ユーザーの一時トークン（generate-db-auth-token） |
Entra ID トークン（MSAL / az account get-access-token） |
IAM サービスアカウントの OAuth2 トークン |
| トークン有効期限 | 15 分 | 約 1 時間（リフレッシュ可能） | 約 1 時間 |
| 設定手順 | RDS で IAM 認証有効化 → DB ユーザー作成（GRANT rds_iam） → IAM ポリシーで rds-db:connect 許可 |
Azure AD 管理者設定 → DB ユーザー作成（FROM EXTERNAL PROVIDER） → Azure RBAC |
Cloud SQL で IAM 認証有効化 → DB ユーザー作成（CLOUD_IAM_USER） → IAM ロール cloudsql.instanceUser.login 付与 |
| 接続数上限 | DB インスタンスサイズ依存（通常の接続と同等） | 通常の接続と同等 | 通常の接続と同等 |
| TLS | 必須（証明書バンドル使用） | 必須 | 必須 |
| 監査 | CloudTrail（トークン生成）+ DB 監査ログ | Azure AD サインインログ + DB 監査 | Cloud Audit Logs + DB 監査ログ |
IAM 認証のメリット:
- パスワードのローテーション不要（トークンは自動失効）
- 個人の IAM ID で接続するため、DB の監査ログで個人を特定できる
- シークレットマネージャーへの DB パスワード保管が不要になるケースがある
- IAM ポリシーで DB アクセス権限を一元管理
注意点:
- IAM 認証には接続確立時にオーバーヘッドがあり、大量の短命接続には向かない
- アプリケーション用途ではコネクションプール + シークレットマネージャー経由のパスワード認証のほうが適切な場合がある
- 運用者の対話的アクセスに IAM 認証、アプリにはシークレットマネージャー経由のパスワード、と使い分けるのが実務的
監査ログの取得と統合
DB アクセスの監査では「誰が」「いつ」「どの DB に」「何をしたか」を追跡可能にする。
踏み台レイヤーと DB レイヤーの両方でログを取得し、SIEM に集約する。
| ログ取得ポイント | AWS | Azure | GCP |
|---|---|---|---|
| 踏み台セッション | SSM Session Manager ログ → S3 / CloudWatch Logs | Azure Bastion 診断ログ → Log Analytics | IAP アクセスログ → Cloud Audit Logs |
| IAM 認証イベント | CloudTrail（GenerateDBAuthToken） |
Azure AD サインインログ | Cloud Audit Logs（IAM トークン発行） |
| DB クエリログ | RDS Performance Insights / CloudWatch Logs（log_statement=all） |
Azure SQL Auditing / Diagnostic Settings | Cloud SQL 監査ログ / pgaudit 拡張 |
| DB 接続ログ | RDS ログ（log_connections=on） |
Azure SQL 接続監査 | Cloud SQL 接続ログ |
| SIEM 統合 | Security Hub → EventBridge → SIEM | Sentinel（KQL クエリ） | Chronicle / SCC |
監査設計の原則:
- ログは書き込み専用・削除不可・別アカウント保管
- 踏み台のセッションログと DB クエリログを時間軸で結合できる設計にする
- 特権操作（DDL、GRANT、大量 SELECT）に対するリアルタイムアラートを設定
- ログ保持期間は最低 1 年（業種により 3 年以上）
関連トピック
クラウドセキュリティの考え方- クラウド（AWS/Azure/GCP）のセキュリティを設計するうえで必須となる責任共有モデル・ゼロトラスト・ガードレール・最小権限・多層防御の基本原則。 クラウドへのセキュアなアクセス- AWS SSO / SSM Session Manager / IAM Identity Center など、ゼロトラストを意識したクラウドインフラへの接続方式。SSH 鍵の直接管理や踏み台サーバーに頼らない運用を実現する。 AWS IAM ベストプラクティス- ルートユーザー保護・IAM Identity Center による SSO 集約・ロール中心設計・最小権限・MFA 強制など、AWS IAM の設計と運用における推奨設定を整理。 シークレット管理- API キー、パスワード、証明書などの機密情報を安全に保管・配布・ローテーションする仕組み。ハードコーディングの防止が基本。 DB アクセス制御- データベースへのアクセスを適切に制限する仕組み。最小権限の原則に基づき、ユーザー・ロール・権限を管理する。