セキュリティサービス
AWSのセキュリティサービス群を理解し、IDサービスの暗号化、秘密情報管理、API保護、脅威検出を学びます。
所要時間
約45分
学べること
- AWS共有責任モデルの考え方
- KMSによる暗号鍵管理とエンベロープ暗号化
- Secrets Managerによるシークレット管理
- WAF・Shield によるアプリケーション保護
- GuardDuty・Security Hub・AWS Configによる脅威検出と監査
- IDサービスにおけるセキュリティ構成
前提知識
目次
- AWS共有責任モデル
- KMS（Key Management Service）
- KMSキーポリシーとIAM連携
- Secrets Manager
- Secrets Manager vs Parameter Store
- WAF（Web Application Firewall）
- AWS Shield
- GuardDuty
- Security Hub
- AWS Config
- IDサービスでの活用
1. AWS共有責任モデル
AWSとユーザーがそれぞれ担うセキュリティ責任の範囲を明確にするモデルです。
┌─────────────────────────────────────────────────────────────┐
│ AWS 共有責任モデル │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ ユーザーの責任 │ │
│ │ 「クラウドの中のセキュリティ」 │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ データの暗号化・整合性・認証 │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ IAM（アクセス管理） │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ OS・ネットワーク・ファイアウォール設定 │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ アプリケーションコード・セキュリティパッチ │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
│ ━━━━━━━━━━━━━━━━━━━━ 境界線 ━━━━━━━━━━━━━━━━━━━━━━━━━━━ │
│ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ AWSの責任 │ │
│ │ 「クラウドのセキュリティ」 │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ コンピュート・ストレージ・ネットワーク │ │ │
│ │ ├───────────── ────────────────────────────────────┤ │ │
│ │ │ ハードウェア/AWSグローバルインフラ │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ リージョン、AZ、エッジロケーション │ │ │
│ │ ├─────────────────────────────────────────────────┤ │ │
│ │ │ 物理的セキュリティ │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
└───────────────────────── ────────────────────────────────────┘
サービスモデルによる責任範囲の違い
| 責任範囲 | IaaS（EC2） | コンテナ（ECS） | サーバーレス（Lambda） |
|---|---|---|---|
| アプリケーションコード | ユーザー | ユーザー | ユーザー |
| データ暗号化 | ユーザー | ユーザー | ユーザー |
| IAM設定 | ユーザー | ユーザー | ユーザー |
| OSパッチ | ユーザー | AWS（Fargate） | AWS |
| ランタイム管理 | ユーザー | ユーザー | AWS |
| ネットワーク設定 | ユーザー | ユーザー | 一部AWS |
| 物理インフラ | AWS | AWS | AWS |
2. KMS（Key Management Service）
KMSは、暗号鍵の作成、管理、使用を一元化するサービスです。
鍵の種類
┌─────────────────────────────────────────────────────────────┐
│ KMS 鍵の種類 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. AWS マネージドキー（aws/サービス名） │
│ ・AWSサービスが自動作成・管理 │
│ ・ユーザーによるキーポリシー変更不可 │
│ ・例: aws/rds, aws/s3, aws/ebs │
│ │
│ 2. カスタマーマネージドキー（CMK） │
│ ・ユーザーが作成・管理 │
│ ・キーポリシー、ローテーション設定可能 │
│ ・クロスアカウントアクセス可能 │
│ ・IDサービスではこちらを推奨 │
│ │
│ 3. カスタマー提供キー（インポートキー） │
│ ・外部で生成した鍵材料をKMSにインポート │
│ ・特殊な規制要件がある場合に使用 │
│ │
└─────────────────────────────────────────────────────────────┘
エンベロープ暗号化
KMSの核心的な仕組みであるエンベロープ暗号化のフローを理解します。
エンベロープ暗号化の流れ（暗号化時）:
1. データキー生成リクエスト
┌──────────┐ GenerateDataKey ┌──────────┐
│ アプリ │ ──────────────────────→│ KMS │
│ ケーション│ │ │
└──────────┘ └────┬─────┘
│
2. KMSがデータキーを生成 │
┌─────────────────────────────────────┘
│
▼
┌──────────────────────────────────┐
│ 平文データキー 暗号化データキー │
│ (Plaintext) (CiphertextBlob)│
│ abcd1234... Enc(abcd1234..)│
└──────┬──────────────────┬────────┘
│ │
3. 平文データキーで 4. 暗号化データキーを
データを暗号化 データと一緒に保存
│ │
▼ ▼
┌──────────────────────────────────┐
│ 暗号化データ + 暗号化データキー │
│ Enc(data) Enc(key) │
└──────────────────────────────────┘
│
5. 平文データキーをメモリから即座に削除
復号化の流れ:
┌──────────────────────────────────┐
│ 暗号化データ + 暗号化データキー │
└──────┬──────────────────┬────────┘
│ │
│ 1. 暗号化データキーを
│ KMSに送信
│ │
│ ▼
│ ┌──────────┐
│ │ KMS │ 2. CMKで復号
│ │ │ → 平文データキーを返す
│ └────┬─────┘
│ │
▼ ▼
3. 平文データキーでデータを復号
│
▼
┌──────────────┐
│ 平文データ │
└──────────────┘
なぜエンベロープ暗号化が必要か
直接KMSで暗号化する場合:
・最大4KBまでのデータしか暗号化できない
・毎回のAPI呼び出しでネットワーク遅延が発生
・KMSのAPI呼び出し制限に抵触する可能性
エンベ ロープ暗号化:
・データサイズの制限なし
・暗号化/復号はローカルで高速実行
・KMS API呼び出しは鍵操作時のみ
・CMKがKMS外に出ることはない（セキュリティ確保）
3. KMSキーポリシーとIAM連携
キーポリシーの構造
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Enable IAM policies",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow ECS task to use key",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/idp-server-task-role"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "*"
}
]
}
アクセス制御の評価
KMS鍵へのアクセスが許可される条件:
キーポリシー AND (IAMポリシー OR グラント)
┌──────────────┐ ┌──────────────┐
│ キーポリシー │ AND │ IAMポリシー │ → 許可
│ Allow │ │ Allow │
└──────────────┘ └──────────────┘
キーポリシーで「IAMポリシーによるアクセスを許可」を
設定しておくことで、IAMポリシーと組み合わせた柔軟な
アクセス制御が可能になる
4. Secrets Manager
Secrets Managerは、データベース認証情報、APIキー、トークン等のシークレットを安全に保存・管理するサービスです。
基本的な仕組み
┌─────────────────────────────────────────────────────────────┐
│ Secrets Manager の仕組み │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. シークレットの保存 │
│ ┌──────────┐ 暗号化保存 ┌──────────────────┐ │
│ │ 管理者 │ ──────────────→│ Secrets Manager │ │
│ │ │ DB接続情報 │ (KMSで暗号化) │ │
│ └──────────┘ └──────────────────┘ │
│ │
│ 2. シークレットの取得 │
│ ┌──────────┐ GetSecretValue ┌──────────────────┐ │
│ │ ECSタスク│ ──────────────────→│ Secrets Manager │ │
│ │ (idp) │ ←──────────────────│ │ │
│ └──────────┘ 復号済みの値 └──────────────────┘ │
│ │
│ 3. 自動ローテーション │
│ ┌──────────────────┐ Lambda ┌──────────┐ │
│ │ Secrets Manager │ ─────────────→│ RDS │ │
│ │ │ パスワード変更 │ │ │
│ └──────────────────┘ └──────────┘ │
│ スケジュールに基づき自動でパスワードを更新 │
│ │
└─────────────────────────────────────────────────────────────┘
RDSとの統合
# ECSタスクからのシークレット取得例（Python SDK）
import boto3
import json
client = boto3.client('secretsmanager')
response = client.get_secret_value(SecretId='idp-server/rds-credentials')
secret = json.loads(response['SecretString'])
# secret = {
# "username": "idp_admin",
# "password": "auto-rotated-password-xxx",
# "engine": "postgres",
# "host": "idp-db.cluster-xxx.ap-northeast-1.rds.amazonaws.com",
# "port": 5432,
# "dbname": "idp"
# }
自動ローテーションの流れ
ローテーションステップ（4段階）:
1. createSecret : 新しいパスワードを生成し保存
2. setSecret : RDSのパスワードを新しい値に変更
3. testSecret : 新しいパスワードで接続テスト
4. finishSecret : ローテーション完了、バージョンラベル更新
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ create │──→│ set │──→│ test │──→│ finish │
│ Secret │ │ Secret │ │ Secret │ │ Secret │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
バージョン管理:
AWSCURRENT : 現在有効なシークレット
AWSPENDING : ローテーション中の新しいシークレット
AWSPREVIOUS : 直前のシークレット（ロールバック用）
5. Secrets Manager vs Parameter Store
| 比較項目 | Secrets Manager | Systems Manager Parameter Store |
|---|---|---|
| 主な用途 | 機密情報（DB認証、APIキー） | 設定値、パラメータ |
| 暗号化 | 必須（KMS） | オプション（SecureString） |
| 自動ローテーション | 組み込みサポート | なし（Lambda自作が必要） |
| RDS統合 | ネイティブ対応 | なし |
| バージョニング | 自動 | あり |
| 料金 | シークレットあたり $0.40/月 + API呼び出し | Standard: 無料、Advanced: $0.05/月 |
| 最大サイズ | 64KB | 8KB (Advanced) |
| クロスアカウント | 対応 | 対応（Advanced） |
使い分けの指針:
DB認証情報、APIキー、トークン → Secrets Manager
理由: 自動ローテーション、RDS統合
アプリ設定値、フラグ、URL → Parameter Store
理由: コスト効率、階層構造
IDサービスの場合:
┌──────────────────────────────┐
│ Secrets Manager │
│ ・RDS認証情報 │
│ ・JWT署名用秘密鍵 │
│ ・外部APIキー │
├──────────────────────────────┤
│ Parameter Store │
│ ・テナント設定 │
│ ・フィーチャーフラグ │
│ ・エンドポイントURL │
└──────────────────────────────┘
6. WAF（Web Application Firewall）
WAFは、ウェブアプリケーションへの悪意のあるリクエストをフィルタリングするサービスです。
ウェブACLの構成
┌─────────────────────────────────────────────────────────────┐
│ WAF ウェブACL 構成 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ウェブACL（Web Access Control List） │
│ │ │
│ ├── ルールグループ 1: AWS マネージドルール │
│ │ ├── AWSManagedRulesCommonRuleSet（一般的な脅威） │
│ │ ├── AWSManagedRulesSQLiRuleSet（SQLインジェクション） │
│ │ └── AWSManagedRulesKnownBadInputsRuleSet（既知の攻撃）│
│ │ │
│ ├── ルールグループ 2: カスタムルール │
│ │ ├── レート制限（同一IPから100リクエスト/5分） │
│ │ ├── 地理的ブロック（特定国からのアクセス拒否） │
│ │ └── IPホワイトリスト（管理者IPのみ許可） │
│ │ │
│ └── デフォルトアクション: Allow（明示的にブロックされない │
│ リクエストは許可） │
│ │
│ 適用先: ALB、CloudFront、API Gateway │
│ │
└─────────────────────────────────────────────────────────────┘
WAFルールのアクション
| アクション | 動作 | 用途 |
|---|---|---|
| Allow | リクエストを許可 | ホワイトリスト |
| Block | リクエストを拒否（403） | 攻撃のブロック |
| Count | カウントのみ（通過させる） | テスト・監視 |
| CAPTCHA | CAPTCHA認証を要求 | Bot対策 |
WAFルール例（JSON）
{
"Name": "rate-limit-token-endpoint",
"Priority": 1,
"Statement": {
"RateBasedStatement": {
"Limit": 100,
"AggregateKeyType": "IP",
"ScopeDownStatement": {
"ByteMatchStatement": {
"FieldToMatch": {
"UriPath": {}
},
"SearchString": "/token",
"PositionalConstraint": "STARTS_WITH",
"TextTransformations": [{
"Priority": 0,
"Type": "LOWERCASE"
}]
}
}
}
},
"Action": { "Block": {} },
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "rate-limit-token"
}
}
7. AWS Shield
AWS Shieldは、DDoS（Distributed Denial of Service）攻撃からAWSリソースを保護するサービスです。
Standard vs Advanced
| 比較項目 | Shield Standard | Shield Advanced |
|---|---|---|
| 料金 | 無料（自動適用） | $3,000/月 |
| 保護対象 | L3/L4 DDoS | L3/L4/L7 DDoS |
| 自動緩和 | あり | あり（より高度） |
| DRT対応 | なし | 24/7 DDoS Response Team |
| コスト保護 | なし | DDoS起因のスケールアウトコスト返金 |
| 可視性 | なし | リアルタイムメトリクス、攻撃診断 |
| WAF統合 | なし | WAFルール自動適用 |
Shield Standardの保護範囲:
┌─────────────────────────────────────┐
│ すべてのAWSアカウントに自動適用 │
│ │
│ L3（ネットワーク層）: │
│ ・UDP反射攻撃 │
│ ・SYNフラッド │
│ │
│ L4（トランスポート層）: │
│ ・TCPフラッド │
│ ・UDP/ICMPフラッド │
└─────────────────────────────────────┘
Shield Advancedの追加保護:
┌─────────────────────────────────────┐
│ L7（アプリケーション層）: │
│ ・HTTP/HTTPSフラッド │
│ ・スロースロリス攻撃 │
│ ・複雑なアプリケーション層攻撃 │
│ │
│ 対象リソース: │
│ ・CloudFront │
│ ・ALB │
│ ・Route 53 │
│ ・Elastic IP │
└─────────────────────────────────────┘
8. GuardDuty
GuardDutyは、AWSアカウントとワークロードに対する脅威を継続的に監視・検出するサービスです。
┌─────────────────────────────────────────────────────────────┐
│ GuardDuty の仕組み │
├─────────────────────────────────────────────────────────────┤
│ │
│ データソース: │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ VPC Flow Logs │ │ CloudTrail │ │
│ │ (ネットワーク) │ │ (API呼び出し) │ │
│ └────────┬────────┘ └────────┬────────┘ │
│ │ │ │
│ ┌────────┴────────┐ │ │
│ │ DNS Logs │ │ │
│ │ (DNS問い合わせ) │ │ │
│ └────────┬────────┘ │ │
│ │ │ │
│ ▼ ▼ │
│ ┌──────────────────────────────────────┐ │
│ │ GuardDuty 分析エンジン │ │
│ │ ・機械学習による異常検出 │ │
│ │ ・脅威インテリジェンスフィード │ │
│ │ ・ルールベースの検出 │ │
│ └──────────────────┬───────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────┐ │
│ │ Findings（検出結果） │ │
│ │ ・重要度: Low / Medium / High │ │
│ │ ・EventBridge → SNS → 通知 │ │
│ │ ・Security Hub に集約 │ │
│ └──────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
主なFindingタイプ
| カテゴリ | 検出内容 | 例 |
|---|---|---|
| Recon | 偵察行動 | ポートスキャン、API列挙 |
| UnauthorizedAccess | 不正アクセス | 通常と異なるリージョンからのAPI呼び出し |
| CryptoCurrency | 暗号通貨マイニング | EC2での不正マイニング |
| Trojan | マルウェア通信 | C&Cサーバーとの通信 |
| Impact | 影響を及ぼす行動 | リソースの不正操作 |
9. Security Hub
Security Hubは、AWSアカウント全体のセキュリティ状態を一元的に管理・可視化するサービスです。
┌─────────────────────────────────────────────────────────────┐
│ Security Hub │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ GuardDuty │ │ Inspector │ │ Macie │ │
│ │ (脅威検出)│ │ (脆弱性) │ │ (データ) │ │
│ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │
│ │ │ │ │
│ └─────────────┼─────────────┘ │
│ ▼ │
│ ┌──────────────────────────┐ │
│ │ Security Hub │ │
│ │ ┌────────────────────┐ │ │
│ │ │ セキュリティスコア │ │ │
│ │ │ 95/100 │ │ │
│ │ └────────────────────┘ │ │
│ │ ┌────────────────────┐ │ │
│ │ │ コンプライアンス │ │ │
│ │ │ チェック │ │ │
│ │ │ ・CIS Benchmark │ │ │
│ │ │ ・AWS Best Prac. │ │ │
│ │ │ ・PCI DSS │ │ │
│ │ └────────────────────┘ │ │
│ │ ┌────────────────────┐ │ │
│ │ │ Finding集約 │ │ │
│ │ │ ・自動トリアージ │ │ │
│ │ │ ・優先度付け │ │ │
│ │ └────────────────────┘ │ │
│ └──────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
10. AWS Config
AWS Configは、AWSリソースの設定変更を継続的に記録・評価するサービスです。セキュリティの観点では「リソース設定がポリシーに準拠しているか」を自動で監視できる点が重要です。
主な機能:
- 設定記録: リソースの設定変更を自動記録（例: セキュリティグループのルール変更）
- Config Rules: リソースがルールに準拠しているか自動評価（例:
encrypted-volumes,restricted-ssh） - 是正アクション: 非準拠リソースの自動修正（例: 暗号化されていないEBSを自動暗号化）
- コンプライアンスダッシュボード: リソースの準拠状況を一覧表示
CloudTrailとの違いやIDサービスに適用すべきConfig Rulesの詳細は、モニタリングを参照してください。
11. IDサービスでの活用
idp-serverのセキュリティ構成全体像
┌─────────────────────────────────────────────────────────────────┐
│ IDサービス セキュリティ構成 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──── 外部からの保護 ──────────────────────────────────────┐ │
│ │ CloudFront + WAF │ │
│ │ ・SQLインジェクション、XSS対策（マネージドルール） │ │
│ │ ・レート制限（/token エンドポイント保護） │ │
│ │ ・地理的アクセス制御 │ │
│ │ ・Shield Standard（L3/L4 DDoS防御） │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
│ ┌──── 暗号鍵管理 ──────────────────────────────────────────┐ │
│ │ KMS │ │
│ │ ・JWT署名鍵（RSA/EC）の管理 │ │
│ │ ・RDSデータの暗号化（保存時暗号化） │ │
│ │ ・S3オブジェクトの暗号化 │ │
│ │ ・EBSボリュームの暗号化 │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
│ ┌──── シークレット管理 ────────────────────────────────────┐ │
│ │ Secrets Manager │ │
│ │ ・RDS認証情報（自動ローテーション有効） │ │
│ │ ・外部IdP連携用シークレット │ │
│ │ ・SMTP認証情報 │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
│ ┌──── 脅威検出・監査 ──────────────────────────────────────┐ │
│ │ GuardDuty → Security Hub → EventBridge → SNS → 通知 │ │
│ │ AWS Config: KMS鍵/SG/S3等のリソース設定監視 │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
WAFルール設計のポイント
IDサービス特有のWAFルール:
1. トークンエンドポイント保護（/token）
・レート制限: クライアントIPあたり100回/5分
・ブルートフォース攻撃対策
2. 認可エンドポイント保護（/authorize）
・レート制限: ユーザーIPあたり30回/分
・自動化ツールによる不正アクセス防止
3. 管理API保護（/api/v1/*）
・IPホワイトリスト（管理者ネットワークのみ）
・追加の認証ヘッダーチェック
4. 共通ルール
・SQLインジェクション対策
・XSS対策
・既知の悪意あるユーザーエージェントブロック
まとめ
| サービス | 役割 | IDサービスでの用途 |
|---|---|---|
| KMS | 暗号鍵管理 | JWT署名鍵、データ暗号化 |
| Secrets Manager | シークレット管理 | DB認証情報、APIキー |
| WAF | アプリケーション保護 | API保護、レート制限 |
| Shield | DDoS防御 | インフラ保護 |
| GuardDuty | 脅威検出 | 不正アクセス検知 |
| Security Hub | セキュリティ一元管理 | コンプライアンス監視 |
| AWS Config | リソース設定監視 | 設定変更の追跡 |
重要なポイント:
- 共有責任モデルを理解し、ユーザー責任範囲のセキュリティを確実に実装する
- エンベロープ暗号化により、大量データの効率的な暗号化が可能
- Secrets Managerの自動ローテーションでDB認証情報を安全に管理する
- WAFのマネージドルールとカスタムルールを組み合わせてAPI保護を実現する
次のステップ
- モニタリング: CloudWatch、CloudTrail等の監視・運用サービスを学ぶ