はじめに
AWS Certified Security - Specialty(SCS-02)に合格したので、勉強中にまとめたメモをベースに重要ポイントを整理してみた。
この記事では、試験対策だけじゃなくて実務でも使える知識を中心にまとめてる。特に「これ知らないとハマる」ってポイントや、「実際の設計で迷いがちな部分」を重点的に書いていくよ。
合格に必要な概念を全て網羅しているわけではないので気をつけて。また、誤ってるところあったらすみません🙏
Identity and Access Management (IAM)
IAM基本
IAM Credential Reportは、アカウント内の全ユーザーの認証情報状況をレポートしてくれる機能。定期的にチェックして、古いアクセスキーとか放置されてるユーザーを見つけるのに便利。
AmazonSSMManagedInstanceCoreは、Session Managerを使う前提の最小限のIAMロール。SSH鍵管理が不要になるから、セキュリティ的にもめっちゃ楽になる。
Tag-based Access Control(ABAC)
タグベースのアクセス制御は、これからのAWSセキュリティの主流になっていく考え方。
**ABAC(Attribute-Based Access Control)**は、ユーザーやリソースの属性(タグ等)を基に動的にアクセス権限を決定する仕組み。従来のRBACだとロールが爆発的に増えちゃうけど、ABACなら管理がめっちゃ楽。
実装のコツ
- リソース側とプリンシパル側に同一のタグキーをつける
- ポリシーで
aws:PrincipalTag
とaws:ResourceTag
を比較 - 例:開発チームは自分たちの
Team
タグがついたリソースだけ操作可能
{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Team": "${aws:PrincipalTag/Team}"
}
}
}
チームは自分たちのタグがついたリソースのみに作成・変更を許可される。新しいリソースを作っても、タグさえ正しくつければ自動的に権限が適用されるから、動的に権限が制御できて超便利。
フェデレーション
企業の既存IDプロバイダーとAWSを連携させる仕組み。
SAML 2.0フェデレーション
- Security Assertion Markup Language 2.0を使ったSSOの実現
- X.509証明書でIdPとの信頼関係を構築
- IdPメタデータ(XMLファイル)を使って設定
主要なIdPサービス:
- Okta - クラウドベースで設定が楽
- ADFS - オンプレミスのActive Directoryと連携
クロスアカウントアクセス
AWS STS AssumeRoleは、一時的な認証情報を取得してクロスアカウントアクセスを実現する。長期的なアクセスキーを配らなくていいから、セキュリティリスクが減る。
Tips: AssumeRoleのセッション時間は最大12時間まで延長可能。デフォルトは1時間だから、長時間のバッチ処理とかだと注意。
IAM Access Analyzer
外部アクセスを分析して、意図しない権限付与を検出してくれる神ツール。
- S3バケットポリシーの設定ミス
- IAMロールの信頼ポリシーの問題
- KMSキーポリシーの外部共有
これらを自動で見つけてくれるから、定期的にチェックしよう。
Cognito User Pool
ユーザー認証とユーザー管理を提供するマネージドサービス。サインアップ、サインイン、MFAなどの機能が全部入ってる。B2Cアプリとかモバイルアプリの認証基盤として使える。
Data Protection
KMS(Key Management Service)
**CMK(Customer Master Key)**の管理は、SCSで超重要なトピック。
grantの仕組み
grantは、KMS権限委譲メカニズム。CMKの使用権限を他のAWSプリンシパルに一時的に委譲できる。
- ポリシーを書き換えずに権限を付与できる
- プログラマティックに権限管理できる
- 取り消しも簡単
インポートキーの特性
外部で作成したキーマテリアルをインポートする場合:
- キーマテリアルを削除すると、CMKの状態が「インポート待ち」になる
- 暗号化・復号化ができなくなる
- でもメタデータ(キーID、ポリシー)は残ってる
- 同じキーマテリアルを再インポートすれば、また使えるようになる
- 有効期限の設定が可能で、期限が来ると自動的にキーマテリアルだけが削除される
Tips: インポートキーは自動ローテーションができない。手動でローテーション計画を立てる必要がある。
自動キー更新の仕組み
これがめっちゃ重要!
- 同じキーIDのまま、365日ごとに内部のバックエンドキー(key material)のみが新しく生成される
- 新しい暗号化要求には、自動的に最新版のバックエンドキーが使用される
- 古いデータは古いキーで復号可能(後方互換性あり)
- 再暗号化しなくても、将来分のデータだけは新しい鍵で守れる
AWS マネージドキー(aws/rdsなど)
- 1年ごとに自動的に新しいキーマテリアルへ置き換わる
- ユーザー側で設定変更は不要
カスタマーマネージドキー
- キーマテリアルをAWSに生成させた対称CMKで、自動ローテーションをオンにできる
- 有効にすれば365日ごとにバックグラウンドでローテーションされる
CloudHSM
AWS CloudHSMは、FIPS 140-2 Level 3準拠の物理HSMを占有できるサービス。
主な特徴:
- 鍵のライフサイクル操作をPKCS#11、JCEなど標準の暗号モジュール経由で実行
- 監査ログはsyslogで取得可能
- AWSからのアクセスは不可能(サポートスタッフも無理)
Tips: CloudHSMとKMSの使い分けは、コンプライアンス要件次第。金融系とか、完全に自分たちで鍵を管理したいならCloudHSM。
S3の暗号化
SSE-KMS(Server-Side Encryption with KMS)
- KMS管理キーでオブジェクトを暗号化
- きめ細かいアクセス制御と監査ログが可能
- CloudTrailでKMS APIコールを追跡できる
SSE-S3(Server-Side Encryption with S3 Managed Keys)
- S3が管理する暗号化キーを使用
- 最もシンプルな方式
- 細かいアクセス制御は不要な場合に使う
Secrets Manager
パスワードやAPIキーの管理に必須のサービス。
GetSecretValue APIの使い方
- デフォルトでKMS暗号化
- RDS向けにはAWSが管理するローテーションLambdaを数クリックで有効化可能
- 90日ごとの自動ローテーション設定がベストプラクティス
ECSタスクでの使い方
- タスク実行ロールに
GetSecretValue
とkms:Decrypt
だけを付与 - 環境変数にSecrets ManagerのARNを指定
- タスク起動時に自動で値を取得してくれる
Systems Manager Parameter Store
Parameter Store Secure Stringは、KMSのカスタマー管理キー(CMK)で暗号化される。
- Lambda実行ロールには
ssm:GetParameter
とkms:Decrypt
を付与 - 月100万リクエストまで無料(Secrets Managerより安い)
- シンプルな設定値の管理ならこっちで十分
使い分けのポイント
- 自動ローテーションが必要 → Secrets Manager
- 単純な設定値の暗号化保存 → Parameter Store
S3 Object Lock
**WORM(Write Once Read Many)**を実現する機能。
- データを一度書き込んだ後は削除・変更不可
- コンプライアンス要件(SOC2、HIPAAなど)への対応
- リテンションモード:
- Governance: 特別な権限があれば削除可能
- Compliance: 誰も削除できない(rootユーザーでも無理)
TLS通信の強制
aws:SecureTransport条件キーを使ったバケットポリシー:
{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::bucket-name/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
aws:SecureTransport
がfalseと判定した全てのリクエストを即座にDenyできる。強制的にTLS(HTTPS)通信のみを許可する。
RDS暗号化の有効化手順
既存の非暗号化RDSインスタンスを暗号化する方法:
- 非暗号化インスタンスのスナップショットを取得
- そのコピーを暗号化を有効にしてコピー
- そのコピーからDBインスタンスを復元
Tips: ダウンタイムが発生するから、メンテナンスウィンドウで実施しよう。
CMKインポートキーの手動ローテーション
インポートしたキーマテリアルは自動ローテーションできないから、手動でローテーション計画を立てる必要がある。
- 新しいCMKを作成
- アプリケーションを新しいCMKに切り替え
- 古いデータは古いCMKで復号可能な状態を維持
- 移行期間後、古いCMKを削除
Infrastructure Security
VPC基本
**ENI(Elastic Network Interface)**は、EC2インスタンスにアタッチされる仮想ネットワークインターフェース。複数のENIを持つことでマルチホーム構成が可能になる。
ルートテーブルのlocalルート
- 自動で作成される
- 削除できない
- VPC内の通信を処理
VPCピアリング
- 両VPCのルートテーブルに相手のCIDRブロックへの経路登録が必要
- 推移的なピアリングは不可(A-B、B-Cがあっても、A-Cは通信できない)
VPCのモニタリング
トラフィックミラーリング
- EC2インスタンスのネットワークトラフィックをコピー
- セキュリティ分析やトラブルシューティングツールに送信
- IDSやIPSの実装に使える
フローログ
- VPC内のネットワークインターフェースを通過するIPトラフィックの情報をキャプチャ
- セキュリティ分析や監査に使える
- S3、CloudWatch Logs、Kinesis Data Firehoseに保存可能
Tips: フローログは全トラフィックじゃなくて、ACCEPT/REJECTのフィルタリングができる。コスト削減のために、必要な情報だけ記録しよう。
セキュリティグループとNACL
セキュリティグループ
- EC2インスタンス単位で適用
- ステートフルファイアウォール
- インバウンド・アウトバウンド通信を制御
- 戻りトラフィックは自動的に許可される
NACL(Network Access Control List)
- サブネット単位で適用
- ステートレスファイアウォール
- 戻りトラフィックも明示的に許可が必要
- **エフェメラルポート(1024-65535)**の許可を忘れずに
エフェメラルポートの話
- ephemeral = 儚い、泡沫、蜻蛉
- クライアント側で一時的に使用される動的ポート
- NACLでアウトバウンド通信を許可する場合、インバウンドでエフェメラルポートを開けないと通信が失敗する
VPC Endpoints & PrivateLink
AWS PrivateLinkは、インターネットを経由せずにAWSサービスやパートナーサービスにアクセスできる仕組み。
インターフェースVPCエンドポイント(サービス利用側)
- パブリックIP、NAT、インターネットゲートウェイを一切経由しない
- 通信先のセキュリティグループで許可すべきIPは、エンドポイントENIのみでOK
- プライベートDNSを有効化すれば、既存のFQDNが自動的にエンドポイントのプライベートIPに解決される
VPCエンドポイントサービス(サービス提供側)
- 自社サービスを他のVPCからPrivateLink経由でアクセス可能にする
- NLBの背後にサービスを配置
実装例:KMSとSNSへのアクセス制限
- インターフェース型VPCエンドポイントを作成(KMS、SNS用)
- KMS、SNSのリソースポリシーに
aws:SourceVpce
条件を追加 - 特定のエンドポイントID以外からのリクエストを拒否
{
"Effect": "Deny",
"Principal": "*",
"Action": "kms:*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:SourceVpce": "vpce-1234567890abcdef0"
}
}
}
これで、トラフィックがバックボーンから一切出ない、完全にプライベートな通信が実現できる。
VPN & Direct Connect
Site-to-Site VPN
- オンプレミスネットワークとAWS VPCをIPsecトンネルで接続
- インターネット経由だけど暗号化されてる
- 帯域は限定的(最大1.25Gbps/トンネル)
Direct Connect プライベートVIF
- 専用線でVPCに接続
- 安定した帯域と低レイテンシ
- インターネットを経由しない
AWS Client VPN
- フルマネージドサービス
- ユーザーがどこにいても、可変IPでもVPC内部へリモートアクセス可能
- 証明書認証で端末を、MFAでユーザー本人を多要素検証できる
Tips: Site-to-Site VPNとDirect Connectは併用できる。VPNをバックアップとして使うのが一般的。
ネットワークトラフィックの分析
フルパケットキャプチャ
- ネットワークトラフィックの全パケットデータを記録
- 詳細なネットワーク分析とフォレンジックに使用
- トラフィックミラーリング + EC2のIDS/IPSで実現
ディープパケットインスペクション(DPI)
- パケットのヘッダーだけじゃなくてペイロードも解析
- アプリケーション層の内容を検査
- マルウェアや不正通信の検出
プロミスキャスモード
- ネットワークインターフェースが自分宛て以外のパケットもすべて受信
- パケットキャプチャに使用
- EC2では有効化できないから、トラフィックミラーリングを使う
TLS関連の用語
- TLS終端: クライアントとサーバー間のTLS暗号化通信をロードバランサーで復号
- インラインDPI: ネットワーク通信経路上でリアルタイムにパケット検査
- シグネチャマッチング: 既知の攻撃パターンとトラフィックを照合
Network Protection
AWS Network Firewall
AWS Network Firewallは、VPCレベルでのステートフルなファイアウォール機能を提供するマネージドサービス。
- Layer 3/4のトラフィック制御
- ステートフルなパケット検査
- IDS/IPS機能
- カスタムルールとマネージドルール
ワークロード単位でのセキュリティポリシー適用が可能。
WAF(Web Application Firewall)
レートベースルールが超便利:
- 個別のIPアドレス単位で閾値を超えたものだけブロック
- 正規ユーザーへの影響を最小化
- ALBへの関連付けはダウンタイムなし、即時反映
導入手順のベストプラクティス
- Countモードでルールを適用(ブロックしない)
- CloudWatch Logsで誤検知をチェック
- ルールをチューニング
- Blockモードへ移行
これで本番トラフィックを止めずに誤検知を避けながら導入できる。
CAPTCHAルール
- ボットと人間を区別
- DDoS攻撃やスクレイピング対策
- CloudFrontと組み合わせて使うのが効果的
対応レイヤー
- Layer 7(HTTP/HTTPS)のみ
- ALB、CloudFront、API Gatewayなどの特定サービスでしか使えない
DDoS対策
AWS Shield Standard
- CloudFrontにデフォルトで組み込まれてる
- 一般的なL3/L4攻撃には効果あり
- 無料
AWS Shield Advanced
- CloudFront、Route53などのエッジサービスに対応
- 大規模なネットワーク層(L3/L4)およびアプリケーション層(L7)のDDoS緩和
- 24時間体制のDDoS Response Team(DRT)への直接アクセス
- DDoS Cost Protection(攻撃による料金増加を補償)
Tips: Shield Advancedは月額3,000ドルかかるけど、大規模サービスならコスト削減効果が大きい。
Load Balancer Security
ALB(Application Load Balancer)
リスナー
- クライアントからの接続リクエストを受け付ける
- ポートとプロトコルを指定
ターゲットグループ
- トラフィックをルーティングする対象をグループ化
- ヘルスチェックの設定
エンドツーエンドTLS暗号化
- クライアント → ALB → バックエンド、すべてTLSで暗号化
- 最高レベルのセキュリティ
再暗号化(TLS on TLS 再ネゴシエーション)
- ALBでTLS通信を一度復号
- 再度新しいTLS接続でバックエンドサーバーに送信
- ALBでコンテンツを検査できるメリット
API Gatewayのリソースポリシー
-
aws:SourceIp
条件キーで元IPを制限 - ALBと組み合わせる場合、ALBのIPレンジを指定
NLB(Network Load Balancer)
Layer 4のロードバランサー。
TLSオフロード
- TLS暗号化・復号処理をNLBに委譲
- バックエンドサーバーの負荷軽減
TLSリスナー
- TLSパススルー(TLS offloadingなし)が選択可能
- クライアントとEC2インスタンス間の単一TLSセッションが維持される
- 途中で復号は行われない
使い分け
- TLSオフロード: NLBで復号、パフォーマンス重視
- TLSパススルー: エンドツーエンド暗号化、セキュリティ重視
ELBのセキュリティポリシー
ELBSecurityPolicy-2020-06とか、複数のポリシーが用意されてる。
- サポートするTLSバージョン(TLS 1.0、1.1、1.2、1.3)
- 暗号スイートの選択
旧式の暗号スイート(使っちゃダメ)
- RC4
- 3DES
- SHA-1
これらは脆弱性があるから、モダンな暗号スイートを選ぼう。
Perfect Forward Secrecy(PFS)
- 鍵交換アルゴリズムにEphemeral Diffie-Hellman(DHE)またはECDHEを使用
- 過去の通信が解読されても、将来の通信は安全
カスタムセキュリティポリシー
- 許可暗号スイートを限定できる
- コンプライアンス要件に合わせてカスタマイズ
DNS & Content Delivery
DNSSEC
**DNSSEC(Domain Name System Security Extensions)**は、DNS応答の完全性と真正性を暗号学的に保証する。
主要コンポーネント
- KSK(Key Signing Key): DNSレコードのデジタル署名を行う
- DSレコード: 親ゾーンに配置されて子ゾーンのKSKを検証
- 信頼チェーン: ルートゾーンから目的のドメインまで各レベルで署名を検証
Tips: Route 53でDNSSECを有効化すると、KSKの管理が必要になる。CloudHSMと連携させることも可能。
CloudFront
Geo Restriction / Geo Blocking
- ISO-3166の国コード単位でビューワーリクエストを許可/拒否
- 403を返却
- コンプライアンス要件への対応に使える
OAC(Origin Access Control)
- CloudFrontからS3オリジンへのアクセスを制限する新しいメカニズム
- OAI(Origin Access Identity)の後継
- より強力なセキュリティ機能
設定手順
- CloudFrontディストリビューションでOACを作成
- S3バケットポリシーでOACからのアクセスのみ許可
- 直接S3へのアクセスをブロック
{
"Effect": "Allow",
"Principal": {
"Service": "cloudfront.amazonaws.com"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::bucket-name/*",
"Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:cloudfront::account-id:distribution/distribution-id"
}
}
}
Certificate Management
ACM(AWS Certificate Manager)
パブリック証明書をALBやCloudFrontに関連づければ、証明書の発行・更新・ローテーションが完全自動化される。
- 証明書の有効期限管理が不要
- 自動更新
- 無料(パブリック証明書のみ)
Tips: ACMで発行した証明書は、us-east-1リージョンで作成しないとCloudFrontで使えないから注意。
Compute Security
EC2
EC2 Nitro System
- AWSの次世代EC2インスタンス基盤
- 専用ハードウェアによる仮想化オーバーヘッド削減
- セキュリティ向上
ENA(Elastic Network Adapter)
- 高性能ネットワーキングを可能にする拡張ネットワークアダプター
- 最新世代のインスタンスで使用
Source/Destination Check
- EC2インスタンスが送受信パケットの送信元・宛先IPをチェックする機能
- NAT機能を使用する際は無効化が必要
OSレベルのファイアウォール
- iptables(Linux)
- Windows Firewall
- セキュリティグループと併用することで多層防御
Container Security
AWS Batch
- 大規模なバッチ処理ワークロードを効率的に実行
- コンテナベースのジョブ管理
EKS Pod
- Amazon EKS(Kubernetes)クラスター内の最小デプロイ単位
- 1つ以上のコンテナをグループ化
- Pod Security Policyでセキュリティ制御
Systems Management
Systems Manager Automation
- 運用タスクの自動化とワークフローの実行
- インシデント対応の自動化に使える
SSM Patch Manager
- EC2インスタンスやオンプレミスサーバーのパッチ管理を自動化
- Patch Baselineでパッチ適用ルールを定義
SSM Run Command
- 複数のEC2インスタンスに対してリモートでコマンドを実行
- スクリプトの一括実行
SSM Agent
- EC2インスタンス上で動作するエージェント
- Systems Managerサービスとの通信を担当
- 最新のAMIにはプリインストールされてる
Email Security
SES(Simple Email Service)
SMTP専用エンドポイント:
email-smtp.<リージョン>.amazonaws.com
- ポート587:STARTTLSを使用したメール送信の標準ポート
- TLS1.2で暗号化したSMTP通信
Tips: SESの送信制限は、サンドボックスモードだと1日200通まで。本番利用には制限解除申請が必要。
Workspace Security
Amazon WorkSpaces
- クラウドベースのデスクトップ仮想化サービス
- リモートワークやBYOD環境でのセキュアなデスクトップアクセス
- MFAや証明書ベース認証にも対応
Incident Response
脅威検知
GuardDuty
Amazon GuardDutyは、機械学習を活用してAWSアカウントとワークロードの悪意のある活動や異常な動作を検出する脅威検知サービス。
脅威を検知すると
- FindingイベントをEventB
ridgeに発行 - Step Functions呼び出し - ワークフロー全体をフルマネージドにオーケストレーション可能
- Lambda発動 → DynamoDB グローバルテーブルへ悪性IPを保存
- 全リージョン・全アカウントからms単位で参照できるキー値ストアが実現可能
DNS脅威検出
- 各VPCに自動的に提供されているAmazonProvidedDNS(.2アドレス)を経由するクエリだけが対象
- EC2インスタンスがこのアドレスに問い合わせを行うだけで、GuardDutyはパッシブにDNSメタデータを収集できる
- DHCPオプションセットにデフォルトのリゾルバーを指定すれば、全ての名前解決トラフィックが確実にGuardDutyに届く
実装のコツ
- 全リージョンで有効化(マルチリージョン展開してる場合)
- Organizationsと統合して、全アカウントで自動有効化
- FindingをSIEMツールに転送して、包括的な監視体制を構築
IDS/IPS
IDS(Intrusion Detection System)
- 侵入検知システム
- ネットワークやシステムへの不正アクセスや攻撃を検出
IPS/IDSエージェント
- リアルタイムでHTTPトラフィックを解析
- シグネチャを自動更新
- トラフィックミラーリングと組み合わせて使う
FIM(File Integrity Monitoring)
- 改ざん検知機能
- ファイルやディレクトリの変更を監視・検出
- コンプライアンス要件への対応
Tips: AWS Marketplaceに、Trend Micro Deep SecurityやPalo Alto Networks VM-Seriesなど、商用IDS/IPSが多数ある。
Logging & Audit
CloudTrail
CloudTrailは、AWSアカウント内のAPI呼び出しを記録する監査サービス。
基本仕様
- デフォルトで直近90日分のイベント履歴を保持
- 長期保存にはS3バケットへの出力が必要
- マルチリージョン対応
暗号化の仕組み
- SSE-KMSで暗号化したオブジェクトをS3に書き込む際、CMKからデータキーを取得するための権限が必要
- CloudTrailサービスロールに
kms:GenerateDataKey
とkms:DescribeKey
を付与
S3バケットポリシーの設定
CloudTrailがログを保存するには、s3:PutObject
とs3:PutObjectAcl
を許可するバケットポリシーが必要。
{
"Effect": "Allow",
"Principal": {
"Service": "cloudtrail.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::bucket-name/AWSLogs/*",
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control"
}
}
}
Organization Trail
Organization Trailを使えば、組織内の全てのアカウントのマネジメントイベントを一箇所に集約できる。
- 各リージョンのEventBridgeにリアルタイム配信
- 新しいアカウントが追加されても自動的に対象になる
- 一元管理で監査が楽
Transit Gatewayのログも含めて、組織全体のネットワークアクティビティを追跡可能。
CloudWatch Logs
CloudWatch Logsエージェント
- EC2インスタンスやオンプレミスサーバーのログファイルをCloudWatch Logsに送信
- カスタムログの収集
- システムログの一元管理
Metric Filter
- CloudWatch Logsのログデータから特定のパターンを検索
- カスタムメトリクスを生成
- 例:エラーログの出現回数をメトリクス化
Subscription Filter
- ログデータをリアルタイムで他のAWSサービスにストリーミング
- Lambda、Kinesis Data Streams、Kinesis Data Firehoseに転送可能
- SIEM連携に使える
CloudWatch Logs Insights
- ログデータを対話的にクエリ・分析
- フルマネージドログ分析サービス
- SQLライクなクエリ言語
ChatOps連携
- CloudWatch AlarmをSNS経由でSlackやMicrosoft Teamsに通知
- インシデント対応の迅速化
Data Streaming & Analysis
Kinesis
Amazon Kinesis Data Firehose
ログの収集とリアルタイム分析に最適。
- 1MiBまたは1秒のいずれか早い方でバッファをフラッシュ
- 秒単位でOpenSearch Serviceにドキュメントを配信できる
- **暗号化(at-rest / in-transit)**あり
- UltraWarm、Cold Storageを併用すれば、7年間の長期保存と再クエリが可能
配信先の選択肢
- S3
- OpenSearch Service
- Redshift
- Splunk
- カスタムHTTPエンドポイント
Amazon Kinesis Data Streams
より低レイテンシが必要な場合はこっち。
- 高スループットのストリーミング収集
- 1秒未満でデータをOpenSearch Ingestion(OSI)パイプラインへ渡せる
- OSIは変換・バッファリングを行い、OpenSearch Serviceにほぼリアルタイムでデータをロード
使い分け
- リアルタイム分析が必要 → Kinesis Data Streams
- バッチ的な処理でOK → Kinesis Data Firehose
Forensics & Investigation
ディスクフォレンジック
ディスクフォレンジックは、記憶装置(ハードディスク、SSD等)から証拠データを科学的に収集・分析するデジタル鑑識手法。
手順
- 侵害されたEC2インスタンスを隔離(セキュリティグループで全通信遮断)
- EBSスナップショットを取得
- 別のフォレンジック用EC2インスタンスにスナップショットからボリュームを作成してアタッチ
- 読み取り専用でマウント
- ログ、ファイルシステム、削除されたファイルを解析
Tips: スナップショットは読み取り専用だから、証拠の完全性が保たれる。
メモリフォレンジック
メモリフォレンジックは、コンピューターのメモリ(RAM)内のデータを解析する手法。
EC2 Rescue for Windows Server
- Live Responseモード
- Windows EC2インスタンスの問題診断と修復
- RAMダンプの取得が可能
RAMダンプの重要性
- 実行中のプロセス
- ネットワーク接続
- 暗号化キー
- マルウェアの痕跡
これらはディスクに残らない情報だから、メモリフォレンジックが必須。
Linux系の場合
-
dd
コマンドやLiME
(Linux Memory Extractor)を使用 -
/proc/kcore
からメモリダンプを取得
カーネルレベルのマルウェアも検出できるのが強み。
オーバーレイネットワークの理解
オーバーレイは、既存のネットワーク上に構築される仮想ネットワーク。VPNやSDNで使用される技術。
フォレンジック調査では、オーバーレイネットワークのトラフィックも考慮する必要がある。
Data Analysis
Athena
Amazon Athenaは、S3に保存されたデータに対してSQLクエリを実行できるサーバーレス分析サービス。
CloudTrailログの分析例
SELECT
useridentity.principalid,
eventname,
COUNT(*) as event_count
FROM cloudtrail_logs
WHERE eventtime BETWEEN '2025-01-01' AND '2025-01-31'
GROUP BY useridentity.principalid, eventname
ORDER BY event_count DESC
LIMIT 100;
Glue Crawler
- データソースを自動的にクロール
- メタデータカタログを作成
- Athenaでクエリできるようになる
Tips: パーティション設定を適切に行えば、クエリコストを大幅に削減できる。日付やアカウントIDでパーティション分けするのが一般的。
Data Discovery & Classification
Amazon Macie
Amazon Macieは、機械学習を用いてS3オブジェクト内のPII(個人識別情報)を自動的に特定し、機密データの所在を可視化するサービス。
検出できる情報
- 名前
- 住所
- クレジットカード番号
- 運転免許証番号
- パスポート番号
- その他のPII
自動分類
- S3バケットとオブジェクトを自動的にスキャン
- 機密度レベルを評価
- 異常なアクセスパターンを検出
アラート設定
- FindingをEventBridgeに送信
- Lambda、SNSで通知
- 自動的な対応アクションも可能
Tips: Macieは従量課金だから、大量のデータをスキャンする場合はコストに注意。まずは重要なバケットだけスキャンして、段階的に拡大していこう。
Compliance and Governance
AWS Config
AWS Configは、リソース設定の変更を記録・評価するサービス。
リアルタイム評価
- リソース設定の変更を最短1分間隔で評価可能
- 違反を検出したらSystems Manager Automationを呼び出して自動復旧
コンプライアンス状態
- COMPLIANT: ルールに準拠
- NON_COMPLIANT: ルールに違反
Compliance Changeイベントが発生した瞬間に、EventBridge → SNSトピックで通知できる。
Aggregator
- Organizationsと組み合わせることで、既存および将来作成される全てのアカウントにルールと修復手順を一括配布
- 複数アカウント・複数リージョンのConfig情報を集約
- 一元管理が可能
よく使うマネージドルール
-
INCOMING_SSH_DISABLED
: セキュリティグループでSSH(ポート22)の受信を無効化しているかチェック -
INCOMING_RDP_DISABLED
: セキュリティグループでRDP(ポート3389)の受信を無効化しているかチェック -
acm-certificate-expiration-check
: ACM証明書の有効期限切れをチェック
資格情報チェック系マネージドルールの仕組み
評価時に必ずGenerateCredentialReport
APIを呼び出して最新レポートを取得する。
- レポート作成中は
ReportInProgress
を返却 - 一旦
NON_COMPLIANT
と評価する - レポート完成後に再評価
カスタムルールの作成
Lambda関数を使って独自のルールを作成できる。
import boto3
def lambda_handler(event, context):
config_client = boto3.client('config')
# リソースの設定を評価
compliance_type = 'COMPLIANT'
# 評価ロジック
# ...
# 評価結果を返す
config_client.put_evaluations(
Evaluations=[
{
'ComplianceResourceType': event['configRuleInvokingEvent']['configurationItem']['resourceType'],
'ComplianceResourceId': event['configRuleInvokingEvent']['configurationItem']['resourceId'],
'ComplianceType': compliance_type,
'OrderingTimestamp': event['configRuleInvokingEvent']['configurationItem']['configurationItemCaptureTime']
}
],
ResultToken=event['resultToken']
)
Application Integration
AWS AppSync
AWS AppSyncは、GraphQLベースのマネージドAPIサービス。
- リアルタイムデータ同期
- オフライン機能
- 複数のデータソース統合(DynamoDB、Lambda、RDS等)
GraphQL
- APIのためのクエリ言語
- クライアントが必要なデータのみを効率的に取得
- Over-fetchingやUnder-fetchingの問題を解決
セキュリティ機能
- Cognitoユーザープール認証
- IAM認証
- API Key認証
- OpenID Connect認証
Organization Management
AWS Organizations
Organizationsは、複数のAWSアカウントを一元管理するサービス。
主な機能
- 一括請求
- アカウント作成の自動化
- ポリシーの一括適用(SCP、Tag Policy等)
- リソースの共有
SCP(Service Control Policy)
- 組織内のアカウントやOUに対して、使用可能なAWSサービスやアクションを制限
- GuardRailsとして機能
- 例:本番環境OUでは特定リージョンのみ使用可能にする
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"ap-northeast-1",
"us-east-1"
]
}
}
}
]
}
Tips: SCPはルートユーザーにも適用される。意図しないサービス利用を組織レベルでブロックできる。
つまづきポイント&対策
KMSの自動ローテーション
間違いやすいポイント
- インポートしたキーマテリアルは自動ローテーションできない
- 非対称キーも自動ローテーションできない
- AWS管理キーは自動的にローテーションされる(無効化不可)
対策
- カスタマー管理キーで、AWSにキーマテリアルを生成させた対称キーのみ、自動ローテーションが有効化できる
- インポートキーの場合は、手動ローテーション計画を立てる
VPCエンドポイントの種類
混同しやすいポイント
- インターフェース型VPCエンドポイント(ENIベース)
- ゲートウェイ型VPCエンドポイント(ルートテーブルベース)
覚え方
- ゲートウェイ型: S3とDynamoDBのみ対応、無料
- インターフェース型: その他のAWSサービス、時間課金
CloudTrailとCloudWatch Logsの違い
CloudTrail
- AWSのAPI呼び出しを記録
- 誰が、いつ、何をしたか
- 監査・コンプライアンス向け
CloudWatch Logs
- アプリケーションログ、システムログを収集
- リアルタイム監視
- 運用監視向け
GuardDutyのDNS脅威検出
見落としがちなポイント
- AmazonProvidedDNS(.2アドレス)を経由するクエリのみが対象
- カスタムDNSサーバーを使ってると検出できない
対策
- DHCPオプションセットでデフォルトのリゾルバーを指定
- カスタムDNSを使う場合は、GuardDutyのDNS保護が効かないことを理解しておく
NACLのエフェメラルポート
よくある間違い
- アウトバウンド通信を許可したのに、レスポンスが返ってこない
原因
- NACLはステートレスだから、戻りトラフィックも明示的に許可が必要
- エフェメラルポート(1024-65535)のインバウンドを開けてないと、通信が失敗する
対策
- インバウンドルールで、エフェメラルポートを許可する
- セキュリティグループはステートフルだから、この問題は起きない
S3の暗号化方式
SSE-S3、SSE-KMS、SSE-Cの違い
- SSE-S3: S3管理キー、シンプル、監査ログなし
- SSE-KMS: KMS管理キー、監査ログあり、きめ細かいアクセス制御
- SSE-C: クライアント提供キー、AWSはキーを保存しない
使い分け
- 監査ログが必要 → SSE-KMS
- シンプルに暗号化したい → SSE-S3
- 完全に自分でキーを管理したい → SSE-C
まとめ&受験のコツ
試験対策のポイント
-
Well-Architected フレームワークを理解する
- セキュリティの柱を中心に、5つの柱すべてを押さえる
- 特に「深層防御」「最小権限の原則」「監査とログ」は重要
-
ハンズオンで実際に触る
- GuardDuty、Config、CloudTrailは必ず触っておく
- VPCエンドポイント、PrivateLinkの動作を理解する
- KMSの暗号化・復号の流れを体験する
-
ユースケースベースで学習する
- 「オンプレミスとAWSを安全に接続するには?」
- 「S3の機密データを保護するには?」
- 「インシデント発生時のフォレンジック手順は?」
このように、シナリオベースで考える癖をつける。
-
公式ドキュメントを読む
- ホワイトペーパー「AWS Security Best Practices」は必読
- サービスごとのセキュリティガイドも目を通す
- FAQは意外と重要なポイントが書いてある
-
マネージドルールとカスタムルールの違いを理解
- AWS Config、GuardDuty、WAFなど、各サービスのマネージドルール
- どんなルールがあるか、一通り把握しておく
試験本番でのコツ
-
時間配分に注意
- わからない問題は後回しにして、確実に取れる問題から解く
-
選択肢の消去法
- 明らかに間違ってる選択肢を消していく
- 「最も適切な」回答を選ぶ(複数正解っぽくても、ベストなものを選ぶ)
-
AWSのベストプラクティスを優先
- 「できる」と「すべき」は違う
- マネージドサービスを優先する選択肢が正解になりやすい
-
セキュリティ>コスト>パフォーマンス
- SCS試験では、セキュリティが最優先
- コストやパフォーマンスとのトレードオフが出てきたら、セキュリティを選ぶ
実務に活かすために
試験対策で学んだ知識は、実務でも超使える。
SCS試験で学ぶ内容は、AWSセキュリティの基礎から応用まで網羅してる。資格取得をゴールにせず、実務で活かせるスキルとして身につけていこう🚀🙆