AWS認定セキュリティ - 専門知識を受験した時の話

この記事の概要

2021/08/15に
AWS認定セキュリティ - 専門知識
(AWS Certified Security – Specialty (SCS-C01))
を受験したので、その時の記録

試験の概要

AWSを利用する上でのセキュリティに的を絞った試験です。

「セキュリティロールを遂行する人を対象としており、AWS プラットフォームのセキュリティ保護についての理解度を評価するものです。」
AWS公式より引用：引用元

◼︎ 試験要項
問題数　　：65問
試験時間　：170分
受験料　　：¥30,000(税別)
合格ライン：100~1000点中750点(約72%)
受験資格　：なし
有効期限　：3年

◼︎ 出題範囲

分野	出題割合
分野 1: インシデント対応	12%
分野 2: ログ収集と監視	20%
分野 3: インフラストラクチャのセキュリティ	26%
分野 4: IDとアクセスの管理	20%
分野 5: データ保護	22%

2021/08時点の最新バージョン(Ver.2.0)のものです。
バージョンアップで範囲等は変更されるので、受験時は公式で確認してください。
AWS 認定 セキュリティ - 専門知識 | AWS

勉強開始前の状態

AWSで動いているWebアプリ開発の業務経験4年(SDKによる開発を2年、インフラの設計構築は1年程度)
アソシエイト3種とSAP取得済み

AWSソリューションアーキテクトを受験した時の話
https://qiita.com/aminosan000/items/24c6dff9532658a5c4d5

AWSデベロッパーアソシエイトを受験した時の話
https://qiita.com/aminosan000/items/89bc76f77626314f3182

AWS SysOpsアドミニストレーターアソシエイトを受験した時の話
https://qiita.com/aminosan000/items/b1765260e8ad1435a366

AWS認定ソリューションアーキテクトプロフェッショナルを受験した時の話
https://qiita.com/aminosan000/items/f172b7add8303926bddc

勉強に使ったもの

1. 試験対策本
要点整理から攻略する『AWS認定 セキュリティ-専門知識』 (Compass Booksシリーズ)
2021/06時点での唯一のSCS対策本、いままで購入していたシリーズとは異なりますが、要点を抑えてあってなかなか良かったです。
ただ、この本に書かれている内容だけだと各サービスの詳細など出題範囲を網羅できていない感じはあるので、その他の教材も合わせて利用します。

2. オンライン練習問題(非公式)
AWS Certified Solution Architect Professional | Whizlabs
AWS認定対策として毎回購入しているWhizlabs、SCSのコースは最新のバージョンの問題が315問(65問×4パターン+サービス別問題40問+無料問題15問)用意されています。

今回50%offクーポンが使えたので、価格は 19.95USD の 50%off で 9.97USD でした。(利用できる最新のクーポンは「whizlabs coupon」で検索)
いつもどおり、Google翻訳で翻訳しながら日本語が怪しい部分は原文とあわせながら利用。

3. AWS公式模擬試験
前回合格時クーポンを利用して、勉強開始時の実力確認に利用
1.の対策本だけ読んだ状態で実施して正答率45%(9/20問)、SAP持ってるしサンプル問題は全問正解だったから余裕かと思っていたが、SAPとは重複していない範囲も広く予想よりスコアは低かった。

4. Black Belt Online Seminar過去資料
サービス別資料 | AWS クラウドサービス活用資料集
対策本や練習問題を解きながら理解不足を感じたサービスの資料を見て学習

5. AWSアカウント
解答/解説やBlack Belt過去資料を見ていてイメージしづらい部分は実際にマネコンでUIを見てみたり、公式チュートリアルに沿って一度触ってみて理解を深める。

6. 公式デジタルトレーニング
Exam Readiness: AWS Certified Security - Specialty
AWS公式の「AWS認定セキュリティ - 専門知識」向けトレーニング資料も用意されているので活用。
日本語で提供されているが、翻訳が怪しい部分もいくつかある・・・
最後の模擬テストも誤訳によって正答を導けなくなっているような部分もあるが、公式模試や実試験と類似の内容もいくつかあったり、試験範囲で問われる内容についてわかりやすく説明してくれているので、受ける価値はある。
(「IAMロール」→「IAMユーザ」となっていたり、「WAF」を「Well Architectedフレームワーク」と訳してしまっていたり)

学習の流れ

以下の流れで勉強実施
対策本(体系的に学習)
　↓
公式模試(実力確認)　
　↓
練習問題(実際の出題内容をインプット・アウトプット)
　↓
Black Belt(苦手箇所の解消)+実操作

忘れそうな部分や、より理解を深めたい部分は自分の言葉で要約しながらメモとしてアウトプットして、毎日勉強開始時に見返す。

勉強時間

約50時間

SAPでは深く問われないサービス
KMS、ACM、GuardDuty、Inspector、Macieあたりの知識とポリシー関連の出題が多いので、公式ドキュメントやネットの記事を見ながら学習。

特にKMS・ACMは理解が浅かったのでBlack Beltも見ながらマネコンで操作してみて時間をかけて理解。

受験後

結果はスコア936で合格、180分使ってちょうど全問きっちり見直しが終わるぐらい。
SAPのときよりは余裕を持って「受かったな」と思いながら提出できました。

防止・監視・インシデント対応の具体的な方法がイメージできるようになったので、仕事で活かせるスキルアップにもなったような気はします。
AWS認定10冠(CLF以外全部)まであと半分！
次は未知の分野Machine Learning、Data Analyticsか…無難にDB、NWか…
また受験したら書いていきます。

勉強になったことメモ

試験のために勉強しながら忘れないように書き溜めたメモたち
※ここに書いてあることはあくまで私が理解が足りないと感じ覚えたかったことで、必ずしも試験で出る範囲ではありません。試験範囲を網羅はしていません。

■ 全般

・予防的統制と発見的統制

• 予防的統制(Preventive Control)：リスクを未然に防ぐ(SCPなど)
• 発見的統制(Detective Control)：リスク発生時に発見して対処する(Config Rules+SSMなど)

・フォレンジック

フォレンジック(Forensics)とは、犯罪の法的な証拠を見つけるための鑑識捜査を指す。
その中でも特に、コンピュータやデジタル記録媒体の中に残された証拠を調査・解析する分野をデジタルフォレンジックという。

・インシデント発生時の対応

インシデント(ウイルス感染や踏み台にされているなど)を検知した場合、セキュリティグループにより論理的にNWから切り離す。
切り離し後、EBSスナップショットやメモリダンプを取得し調査する。
ASG配下のインスタンスの場合はスナップショット取得等のための停止によりターミネートされないよう、先にASGからデタッチする。

■ 監査

・AWS Artifact

下記の第三者による監査レポートをダウンロードできるサービス。

• Global Financial Services Regulatory Principles
• ISO
• Payment Card Industry(PCI)
• Service Organization Control(SOC)
• Quality Management System Overview

・AWS管理ポリシー

AWS管理ポリシーの中には監査向けなどの職務機能のポリシーがある。

職務機能	AWS管理ポリシー名
管理者の職務機能	AdministratorAccess
請求職務機能	Billing
データベース管理者の職務機能	DatabaseAdministrator
データサイエンティストの職務機能	DataScientist
デベロッパーパワーユーザーの職務機能	PowerUserAccess
ネットワーク管理者の職務機能	NetworkAdministrator
読み取り専用アクセス	ReadOnlyAccess
セキュリティ監査の職務機能	SecurityAudit
ユーザー職務機能のサポート	SupportUser
システム管理者の職務機能	SystemAdministrator
表示専用のユーザーの職務機能	ViewOnlyAccess

※補足

• SupportUser：サポートに問い合わせするためのポリシー
• ViewOnlyAccess：ReadOnlyAccessと似ているが、Describe、Listなどリソースの存在やメタデータのみ表示できるポリシー

・認証情報レポート

監査のための情報として、アカウントのすべてのユーザーと、ユーザーの各種認証情報 (パスワード、アクセスキー、MFA デバイスなど) のステータスが示された認証情報レポートを生成しダウンロードすることができる。
認証情報レポートは、マネコン(IAMのコンソールから)、AWS SDK、CLI、またはIAM APIから取得できる。

・AWS Configの活用

AWS Configを利用することで利用中のAWSリソースのレポートを生成することができる。

■ AWS IAM

基本は以前勉強したことの思い出し
AWS IAM再入門

・IAMアクセスアドバイザー

アカウント内の個々のIAMリソースのアクセス可能なAWSサービスと最終アクセス履歴の取得ができる。

・IAMアクセスアナライザー

対称リソースのリソースベースポリシーを分析して信頼ゾーン(自アカウント or Organizations全体)外部のエンティティからアクセス可能になっていないか調査できる。

・アクセス許可の境界(Permission Boundary)使い所

OUやアカウント単位で許可範囲を絞りたいときはSCPだが、特定のロールに対して許可範囲を絞りたいときはPermission Boundaryを利用する。

・ポリシーの条件演算子

意外と知らない演算子があって勉強になったのでメモ
模試や本番試験でもポリシーが問題文や選択肢に登場する問題は結構多いので、どんなものがあるかは要把握。

• Stringxxx系は大文字/小文字区別ありなし(IgnoreCase)とワイルドカードありなし(EqualsorLike)がある
• 一部のサービスにはArnEquals、ArnLikeが使える
• 全ての条件演算子の末尾にIfExistsを追加できる ※条件キーが存在しないときtrue
• Nullは条件キー自体の存在有無をチェックする

CLIによるアクセスの際はaws:MultiFactorAuthPresentキー自体が存在しないので、↓のようにIfExistsをつけないとCLIでの操作にMFAを強制できない。

{
  "Effect" : "Deny",
  "Condition" : { "BoolIfExists" : { "aws:MultiFactorAuthPresent" : "false" }
}

参考：
https://aws.amazon.com/jp/premiumsupport/knowledge-center/mfa-iam-user-aws-cli/

・グローバル条件キー

KMSキーポリシーやS3バケットポリシーでは専用の条件キー(kms:xxx、s3:xxx)があるが、これらのリソースベースポリシーや、ロールベースポリシーで共通で利用できる条件キーもある。

例）

• aws:SourceVpceはKMSやS3にVPCエンドポイントを作成した際、アクセス元のVPCを制限する際に利用
• aws:TokenIssueTimeは一時的な認証情報を利用している(アクセスキーを利用していない)場合のみ許可する際等利用

・アシュームロールのセッション時間

アシュームロールで引き受けたロールのセッション時間はそのIAMロールの設定で変更できる。
秒単位で3,600(1時間)~43,200(12時間)の範囲を指定できる。

■ AWS Systems Manager

SSMはサーバを管理/運用するための複数の機能群をまとめたサービス
主な機能は以下

機能名	内容
セッションマネージャー (Session Manager)	マネコン上でインスタンスにSSHやPowerShellで接続できる セキュリティグループの許可やSSHキーの登録も不要、認証をIAMに集約できる デフォルトの「ssm-user」は権限が強いため、「Run As」設定を利用することが推奨される
メンテナンスウインドウ (Maintenance Windows)	Cron式またはRate式でスケジュールを設定し、この時間内にAutomationなどのタスクを実行させるよう事前定義できる。
実行コマンド (Run Command)	インスタンスに対するコマンドの実行を自動化する 複数のサーバに対し一括で同時にコマンドを実行できる 同時に実行するサーバのレート(割合)を指定することもできる
オートメーション (Automation)	定期的に実行が必要な運用管理タスクを自動化する 複数の処理ステップを「Automation Document」として記載(JSON or YAML) "複数ステップ"の定義ができることとAWSサービスの設定変更などができることがRun Commandとの違い
ステートマネージャー (State Manager)	サーバを予め定義された状態に維持する為に利用 Run CommandとAutomationを定期実行させる
インベントリ (Inventory)	インストールされたソフトウェアの情報を一覧表示する S3へインベントリ情報を同期することもできる AWS Configの「ec2-managedinstance-inventory-blacklisted」を利用するとBLに定義した禁止SWのインストールを検知することもできる
パッチマネージャー (Patch Manager)	パッチの適用状況の確認および自動適用を行える パッチベースラインとして対象OSバージョンや適用対象のパッチの重要度、公開後の日数を設定する パッチ適用状況のレポート生成も可能になった
パラメータストア (Parameter Store)	パスワードや環境変数などの複数のAWSサービスで共有で利用したいパラメータを保存する
ドキュメント (Document)	Run CommandやState Managerから実行するアクションを保存(定義)することができる 事前定義されたマネージドのDocumentもある
OpsCenter	AWS上で発生したイベントを管理する。自動でチケット起票させられるインシデント管理ツール
Explorer	インスタンス数、パッチ適用状況、OpsCenterのイベント状況をダッシュボードで確認することができる マルチリージョン、マルチアカウント対応
Change Calendar	Cronでは表現できないような、カレンダー形式のスケジュールを定義し、Automationなどの実行を許可/拒否ができる(WL/BLどちらか選べる) iCal形式で保存され、EventBridgeとの連携によりLambdaなどの実行も可能(2020/11より追加)
AppConfig	アプリケーションの設定データを管理、LambdaやEC2上のアプリケーションを停止することなく安全に、設定を更新できる デプロイするインスタンスの比率設定などもできる
コンプライアンス Compliance	パッチコンプライアンス、および設定の不整合についてマネージドインスタンスのフリートをスキャンするために使用できる
フリートマネージャー (Fleet Manager)	統合されたユーザーインターフェイスで、AWSまたはオンプレミスで実行されているサーバー群をリモートで管理できる 1つのコンソールからサーバーフリート全体の正常性とパフォーマンスステータスを表示できる

これらを組み合わせてサーバを管理する
例 )

1. Documentで実行内容を定義
2. Run Commandで1のDocumentで実行するコマンドと対象サーバを定義
3. メンテナンスウインドウで2のRun Commandの実行スケジュールを定義
4. Change Calendarで例外的に実行させない日時を定義

■ AWS Config

AWS Configでできること

• 設定の変更履歴を確認
• 設定変更を検知し、通知や自動修復
• AWSリソースの利用状況レポートの生成

「高度なクエリ」を利用することでSQLにより特定の条件で設定変更のイベントを検索することもできる。
事前定義されている「マネージドルール」とLambdaで自由に実装する「カスタムルール」がある。
主要なマネージドルールは以下

ルール名	内容
approved-amis-by-id	実行中のインスタンスが指定したAMI IDになっているか
ec2-instance-no-public-ip	インスタンスにパブリックIPが関連付けされていないか
encrypted-volumes	EBSボリュームが暗号化されているか
restricted-ssh	セキュリティグループのインバウンドSSHのIPアドレスが制限されているか
rds-instance-public-access-check	RDSパブリックアクセスが無効になっているか
cloudtrail-enabled	CloudTrailが有効になっているか
required-tags	指定したタグがリソースに設定されているか
vpc-flow-logs-enabled	VPC Flow Logsが有効になっているか
guardduty-enabled-centralized	GuadDutyが有効になっているか
iam-password-policy	IAMパスワードポリシーが文字数、記号などの要件を満たしているか
iam-root-access-key-check	rootユーザのアクセスキーが作られていないか
iam-user-mfa-enabled	IAMユーザのMFAが有効になっているか
access-key-rotated	アクティブなアクセスキーが指定された日数内にローテーションされているか(指定可能な日数は最大90日)
s3-bucket-public-read-prohibited	S3のパブリック読み込みが禁止されているか
s3-bucket-public-write-prohibited	S3のパブリック書き込みが禁止されているか
s3-bucket-server-side-encryption-enabled	S3のサーバサイド暗号化が有効になっているか

Configルールに反していることを検知した場合のアクションとして自動修復を設定する方法は以下の2種類

• System Manager Automationによる事前定義された修復(2019年9月追加、実装不要)
• ConfigをCloudWatchイベントのイベントソースに設定し、Lambdaのトリガーにする

カスタムルールによるチェックは1,3,6,12,24hの定期実行が可能。

■ AWS CloudTrail

• CloudTrailのログを保護する方法はいくつかある
  • KMSを利用した暗号化：利用するCMKのポリシーにより操作できるユーザを絞る
  • MFA Delete：S3の機能によりMFAを利用しないと削除できないようブロックする
  • 別アカウントへの出力：ログの保管先は異なるアカウントのバケットも指定できるため、別アカウントのバケットへ出力することで保護する
• CloudTrailを利用した検知はCloudWatch LogsのアラームとCloudWatchイベントのどちらかで行える。CloudWath Logsのほうが細かい検知が可能だが、CloudWatch Logsの利用料もかかってくるため、コストが増える。
• CloudTrailで取得できるイベントは以下の3種類、デフォルトで有効なのは管理イベントのみ

イベント	内容
管理イベント	マネコンへのログインとAWSリソースの作成・変更・削除などの管理操作
データイベント	S3バケット上のオブジェクトへの操作、Lambda関数の実行等のデータプレーンオペレーション
インサイトイベント	AWSアカウント内で検知された異常なアクティビティ

• CloudTrailの証跡はデフォルトでSSEが有効

ログファイルの整合性の検証

CloudTrailがS3へ保存したログファイルが変更、削除されなかったかどうかを判断するための機能。
証跡の作成時にこの機能を有効にするとログファイルのハッシュ(ダイジェストファイル)がS3に作成される。

アカウントへの不正アクセスの疑いがある場合、下記のAWS CLIでログには変更が加えられていないことを検証できる。

コマンド例

aws cloudtrail validate-logs \
  --trail-arn arn:aws:cloudtrail:us-east-2:111111111111:trail/example-trail-name \
  --start-time 2015-08-31T22:00:00Z \
  --end-time 2015-09-01T19:17:29Z \
  --verbose

■ AWS X-Ray

サービス間のリクエストをトレースできる。
対応するサービスはEC2, ECS, Lambda, Elastic Beanstalk(Java, Node.js, .NET)
X-Ray SDKの統合(ライブラリのインストール+初期化処理の実装)とX-Rayエージェントのインストール(EC2, ECSの場合)が必要

■ Amazon QuickSight

マネージド型のBI(ビジネス・インテリジェンス)サービス、以下をデータソースとしてビジネス分析のための可視化を行える。

• Amazon Athena
• Amazon Redshift
• Amazon Aurora
• MySQL(オンプレも可)
• PostgreSQL(オンプレも可)
• S3(CSV/TSV/CLF/ELFのテキストファイル)※ELBアクセスログなどの圧縮ファイルの場合、Athenaを経由
• その他SaaS(Salesforceなど)

■ AWS KMS

覚えることが多いので個別にまとめ

■ AWS CloudHSM

特徴

• 対称キーと非対称キー両方対応
• 対障害性や可用性はユーザが担保(クラスター作成時にVPCとAZを指定できる)
• KMSよりコストがかかる

目的

• 専用のHWが必要などのコンプライアンス要件がある場合
• キーの管理をAWSに委任したくない(AWSからもキーにアクセスさせない)場合
• キーをVPC内に配置してアクセス制御をしたい場合

■ AWS Certificate Manager(ACM)

・複数リージョンでの適用

ACMで発行した証明書エクスポートやリージョン間のコピー不可、複数リージョンで同一ドメインを利用したい場合それぞれで作成が必要。

・証明書の自動更新

自動更新を行うために必要な前提条件

• 証明書の各ドメインとHTTPS接続を確立できる状態であること
• 各接続で返される証明書がACMの証明書と一致すること
• ACMに統合されるサービス(ELB等)に関連付けられていること
• ACMが証明書に記載されているドメイン名を検証できること
• インポートされた証明書ではないこと

・プライベートCA

プライベートCAはリージョン単位で作成が必要。
ACMのプライベートCAでは監査レポートをS3に出力できる。監査レポートにはCAが発行/取り消しした証明書のARN、サブジェクト、有効期限などの情報が含まれる。

SNI(Server Name Indication)

一つのサーバで複数の証明書を利用する技術(AWS固有ではない)
ALBもSNIに対応しているため、1つのリスナーに複数の異なるドメインの証明書を登録できる。

■ AWS Secrets Manager

シークレットの管理サービス、RDSの認証情報の自動ローテーションが簡単に行える
シークレットのローテーションを有効にすると、AWS管理のLambda関数がデプロイされる。
SSM Parameter StoreのSecureStringでも似たことができる。自動ローテーションが必要な場合Secrets Manager、そうでない場合Parameter Storeが推奨。

・マルチユーザローテーション

シークレットのローテーション時に新しいシークレットが有効になるまでの間ダウンタイムが発生する可能性がある。
マルチユーザローテーションを有効にすることで、2つのシークレットが交互に利用されるため、新しいシークレットが作成された後も古いユーザが即時無効にはならない。

■ Amazon VPC Flow Logs(VPCフローログ)

VPC Flow Logsで取得できるのは送信元/送信先IP、送信元/送信先ポート、通信許可/遮断などのNWの基本情報。
ログ保存先はCloudWatch Logs/S3から選択できる。保存のコストはS3のほうが低い(0.025USD/1GB:0.76USD/1GB)ため、監視の要件がなく、検索の頻度が低い場合S3推奨。
監視目的でCloudWatch Logsを利用する場合、古いログはアーカイブする設定を有効にするとコストが削減できる。
利用にはENI単位でフローログの作成(有効化)が必要。

■ Amazon Macie

機械学習を使ってS3に保存されている機微情報(機密データ)を検出できる。
個人識別情報(PII)などのデータを特定し、通知や保護処理を実行することが出来る。
Macieで機密データが検知されるとCloudWatchイベントに送信されるため、SNSによる通知やLambdaによる保護処理を設定する。
検知は15分以上(設定可能)の間隔で定期実行

検出できる情報の例

• 氏名フルネーム
• メールアドレス
• クレジットカード番号、有効期限
• 運転免許証ID(米国)
• 生年月日
• AWSシークレットキー
• OpenSSHプライベートキー

日本語の情報検知には対応していないが、「カスタムデータ識別子」として正規表現によるパターンマッチングもできる。

■ Amazon GuardDuty

AWSの各種ログを自動的に取得して、機械学習で分析して脅威を検知+通知してくれる、2017年に公開
設定は有効/無効と検知設定のみ(ほぼ)
GuardDutyのインプット情報は以下の3つ

• CloudTrail
• VPC Flow Logs
• DNS Logs

GuardDutyで検知できる脅威は以下

一部抜粋：

• アカウント内のEC2インスタンスが暗号通貨関連のIP|ドメインへリクエストしている
• アカウント内のEC2インスタンスがブルートフォース攻撃と思しき挙動をしている
• S3のパブリックアクセスブロックがアカウントレベルで無効になった
• S3またはIAM APIが特定のLinuxディストリビューション(KaliLinux|ParrotLinux|PentooLinux)から呼び出された
• アカウントルートのクレデンシャルでAPIが呼び出された
• CloudTrailが無効にされた
• IAMのパスワードポリシーが弱化された

■ Amazon Inspector

EC2にエージェントをインストールし、潜在的なセキュリティ上の問題(NWアクセス及び実行されているアプリケーションの問題)を発見するホスト型脆弱性診断サービス。
※ネットワーク評価はエージェントのインストールなしで実行可能。

ルールパッケージ	ルール内容	評価種別
Network Reachability(ネットワーク到達可能性)	Security Groupなどの各種ネットワークリソースの設定を分析し、 インターネット、Direct Connect、VPCピアリングなどの外部ネットワークから、EC2インスタンスに到達できるかどうかを評価、ポート開放状況だけでなく、アクティブなリスニングプロセスの有無も評価される	ネットワーク評価
共通脆弱性識別子(CVE)	CVEの該当有無チェック 東京リージョンチェック対象リスト	ホスト評価
Center for Internet Security (CIS) ベンチマーク	Center for Internet Security (CIS) ベンチマークに基づいたチェック	ホスト評価
Amazon Inspector のベストプラクティス	SSHのrootログイン、SSHバージョン、SSHパスワード認証、パスワード設定、DEPの有効化、アドレス空間配置のランダム化（ASLR）の有効化、システムディレクトリでのroot以外のユーザ書き込み権限有無	ホスト評価

■ AWS Shield

AWS ShieldはAWSのNWインターフェースになるサービスに無料で自動適用、Shield Advancedは有料

・Shield Advancedを利用する目的

Shield Advancedを有効にすることでAWS DDoSレスポンスチーム(DRT)に対応を支援してもらえる。
DRTはDDoS攻撃を緩和するWAFルールの作成や攻撃の分析/診断/可視化などを提供してくれる。
DDoS攻撃による使用量の増加による請求を無効にする「スケーリングへの DDoS コスト保護」を受けられる。

■ AWS Security Hub

GuardDutyやMacie、Inspector、Firewall Manager、IAM Access Analyzerなどによる検知状況を1箇所で確認できる、2019/6公開
CIS AWS Foundations BenchmarkやPCI DSSといった基準に従ったコンプライアンスチェックもできる

■ Amazon Detective

VPC Flow Logs、CloudTrail、GuardDutyなどをインプットに、潜在的なセキュリティ問題や不審なアクティビティを分析、調査できる。2020/4公開
過去のログやイベント情報をグラフで視覚化することができ、時間帯、実行数、実行内容など傾向分析に利用できる。

■ AWS Audit Manager

AWSの使用状況を継続的に監査して、リスクの評価方法と規制や業界標準への準拠を簡素化する際に役立つサービス

■ AWS WAF

AWS WAFのロギングを行うためにはKinesis Data Firehoseにログを送信させる必要がある。
ALBにWAFをアタッチした状態でALBのログを有効にしてもALBのログで見られる情報はWAFに弾かれて403を返したことだけ。
WAFの設定で登場する要素の関係は「条件 in ルール in ACL」

・AWS WAFで設定可能な条件

条件	リクエストを許可またはブロックする基準
クロスサイトスクリプティングの一致	リクエストに悪意のあるスクリプトが含まれているおそれがあるかどうか
IPの一致	送信元のIPアドレス
地理的な一致	リクエストの発生元の国
サイズの制約	リクエストが指定した長さを超えているかどうか
SQLインジェクションの一致	リクエストに悪意のあるSQLコードが含まれているおそれがあるかどうか
文字列の一致	リクエスト内の文字列
正規表現の一致	リクエスト内の正規表現パターン

■ Amazon Route53 DNS Resolver Firewall

VPCからのアウトバウンドDNSリクエストを保護する。
悪意のあるサイトへの不良な名前解決をさせないなど、DNSを悪用した攻撃からの保護に利用。2021/04公開、現時点では試験には出ないはず。

■ AWS Firewall Manager

複数のアカウントおよび複数のリソース間でFirewallに関する設定(AWS WAF,AWS Shield Advanced、Amazon VPC セキュリティグループ、AWS Network Firewall、およびAmazon Route53リゾルバーDNSファイアウォール)をまとめて管理できる。保護を一度設定するだけで、既存のアカウントやリソース、追加する新しいリソースに自動的に適用させることができる。2018/5公開

■ AWS Network Firewall

VPC向けのステートフルなマネージドネットワークファイアウォールのサービス。
インターネットゲートウェイ、NATゲートウェイ、VPC、DirectConnectなど "VPCの境界で" トラフィックをフィルタリングすることができる。2020/11公開
※あまりユースケースは多くない、試験でもでないかもしれない。

↓AWSのファイアウォール関連のサービスや機能の比較、使い分け

サービスor機能	用途/概要
AWS Firewall Manager	アカウントをまたいだファイアウォール管理
Amazon Route53 DNS Resolver Firewall	DNSを悪用した攻撃からの保護
AWS Network Firewall	VPCピアリングやDX利用時のVPC間のアクセス制御
AWS WAF	CloudFrontやELBなどのネットワークの入り口でのIP制限やL7の要素による防御
Network ACL	サブネット単位のアクセス制御
Security Group	ENI単位(インスタンスやELB単位)でのアクセス制御

↓覚えやすいように図にしてみた

■ AWS Single Sign-On

既存Directoryサービスや外部IDPを利用した認証でAWSへログインできる。
複数アカウントへのスイッチロールも可能。
ActiveDirectory(AD)を利用する場合ADのグループとIAMロールの紐付けを行うことで、権限を制御する。
前提条件としてAWS Organizationsの「すべての機能」が有効になっている必要がある。

■ Amazon Cognito

・Cognitoの２つのプール

プール	目的
ユーザープール	・ユーザそのものを登録するプール、Cognitoのみで認証をする場合に必要 ・API Gatewayのオーソライザーに設定するのはこっち
IDプール	・ユーザに一意のIDを作成し保存するプール、その他のSAMLやWEBIDフェデレーションで認証した結果に対し、認可をするのに利用 ・ゲストログインが可能にするための許可設定はこっち

• スコープ：ユーザ属性の定義(name、email、profileなど)
• アプリIDとアプリシークレット：IdPとの紐付け/認証のための情報

・ユーザープールワークフローのカスタマイズ

Lambdaトリガーを利用し、認証フローをカスタマイズすることができる。

■ AWS Direct Connectにおけるセキュリティ

AWS Direct Connect(DX)を利用することでVPCと企業NWを物理的に専用線接続できるが、DXの通信は暗号化されないため、「暗号化」という要件が含まれる場合、VPNと組み合わせる必要がある。DXでVPNを利用する場合パブリック接続の必要がある。

■ Amazon CloudFrontにおけるセキュリティ

• ビューワープロトコルポリシー：CloudFrontでHTTPSを強制させる設定
• OAI(オリジンアクセスアイデンティティ)：S3バケットの読み取りをCloudFront経由のみに制限するための機能

■ Amazon Kinesisにおけるセキュリティ

・ストリームの暗号化

サーバサイド暗号化機能を利用することでKinesisストリームストレージレイヤーの書き込み時にKMSのCMKにより暗号化される。

・KCLに必要なポリシー

KCLを利用するIAMユーザまたはIAMロールはDynamoDBとCloudWatchのWriteを許可する必要がある。
DynamoDBでのアプリケーションの状態情報の保持、CloudWatchへのメトリクス送信を行うため。

■ Amazon DynamoDBにおけるセキュリティ

・DynamoDBの暗号化

DynamoDBに格納するデータはKMSのCMKで強制的に暗号化される。
テーブル作成時にCMKの種類を選択できる。
テーブル作成後の変更も可能。
DynamoDBとの通信はAPI経由でHTTPSで行われるため、必然暗号化される。

・DAXの暗号化

DAXはクラスター作成時に暗号化の有効/無効を選択する。作成後の変更は不可。

■ Amazon S3におけるセキュリティ

・バケットポリシーの条件キー

バケットポリシーのConditionとして指定するキー名は知らないと答えられないので覚える
※逆に基本的なものを知っておけばこれだけで得点につながる

条件キー	内容	値
s3:x-amz-grant-full-control	リクエストにs3:x-amz-grant-full-controlヘッダーが含まれる	正規ユーザID (例："id=AccountA-CanonicalUserID")
s3:x-amz-acl	オブジェクトACLの付与	ACL名
s3:x-amz-server-side-encryption	サーバサイド暗号化が有効	暗号化アルゴリズムを表す文字列
s3:x-amz-copy-source	コピー元バケット	バケット名とオブジェクトキーを表す文字列 (例："bucket/folder/*")
s3:VersionId	オブジェクトのバージョンID	バージョンID
s3:x-amz-storage-class	オブジェクトのストレージクラス	ストレージクラスを表す文字列 (例："STANDARD_IA")
s3:TlsVersion	TLSバージョン ※"NumericGreaterThan": {}で指定したバージョン以上かを条件にできる	TLSバージョンを表す数値
s3:LocationConstraint	バケットのリージョン	リージョンを表す文字列
s3:prefix	オブジェクトキーのプレフィックス	オブジェクトキーのプレフィックス

・ポリシーと2つのACL

ACLにはバケットACLとオブジェクトACLがある。

種類	用途
バケットポリシー	バケット全体へのアクセス制御、ポリシーなのでJSON
バケットACL	・アカウント単位のアクセス許可のみ設定できる、バケットポリシーのような条件付きの許可はできない。 ・明示的な許可のみ設定するWL方式 ・S3のアクセスログの保存先バケットに対し使用が推奨される。それ以外のバケット全体へのアクセス制御はバケットポリシーを利用する。マネコンやCLIのオプションで設定。
オブジェクトACL	・アカウント単位のアクセス許可のみ設定できる、バケットポリシーのような条件付きの許可はできない。 ・明示的な許可のみ設定するWL方式 ・クロスアカウントアクセスを行う場合、オブジェクトの所有者がオブジェクトACLにより権限を制御する。 ・オブジェクト単位でアクセス制御を行いたい時。マネコンやCLIのオプションで設定。

・データ格納時の暗号化

SSE(サーバサイド暗号化)の種類と使用するキー

種類	キー
SSE-KMS	カスタマー管理CMK
SSE-S3	AWS管理CMK
SSE-C	ユーザ指定のキー

SSE-CはS3へのAPIリクエスト時にパラメータとしてキー情報を指定する。
AWS上にキー情報が保存されない。

その他

レプリケーション設定時は双方のバケットにバージョニング設定必須

・Glacier

S3 Glacierに保存されるデータは自動的にAWS管理キーで暗号化される。
それ以外のキーで暗号化したい場合、クライアントサイド暗号化を利用する。

・オブジェクトのロック

ユーザの操作ログなど修正が許されないオブジェクトはGlacierのボールトロック(VaultLock)を行うことで変更や削除ができなくなる。
ボールトロックは下記の通りAPI Callにより状態遷移する。

API Call	Call前の状態	Call後の状態	備考
ロック開始(InitiateVaultLock)	ロックなし	テスト状態(InProgress)	ボールトロックポリシーをボールトに関連付ける
ロック完了(CompleteVaultLock)	テスト状態(InProgress)	ロック状態(Locked)	ボールトロックを確定させる
ロック中止(AbortVaultLock)	テスト状態(InProgress)	ロックなし	ボールトロックを取り消す

テスト状態(InProgress)移行時にロックIDが払い出され、24時間の間次の状態遷移待ちの状態となる。
この間にポリシーに問題がないか検証を行う。

通常のS3もオブジェクトロックの機能がある。バケット作成時に有効化が必要で、バージョニングも合わせて有効にする必要がある。
リテンションモードをガバナンスモードとコンプライアンスモードの2種類から選択する。

モード	内容
ガバナンスモード	一部のユーザにはロック解除を許可
コンプライアンスモード	rootアカウントを含めたすべてのユーザに対して変更を拒否

■ その他忘れそうなことおさらい

・EC2接続用キーペアの秘密鍵を削除してしまったとき

1. 新しいキーペアの生成
2. ルートボリュームを別のインスタンスに接続し、ボリューム上の/home/ec2-user/.ssh/authorized_keysファイルを新しい公開鍵で上書きする

インスタンスを作り直しても問題ない場合、AMI作成→新規作成時に別のキーペア指定でもOK

・2種類のVPCエンドポイント

• ゲートウェイエンドポイント：DynamoDBとS3のみ
• インターフェイスエンドポイント：その他

・リソースベースのポリシーが存在するAWSリソース例

• S3バケット
• CMK
• API GatewayのAPI
• Lambda関数
• SQSキュー