先日、AWS認定セキュリティ専門知識の試験を受験し、合格しました!
その記録を残しておきます。
今回の受験は、前回のSysOps Administratorの1週間後です。AWSの資格としては8個目、今月(2021年12月)は3個目です。
2021年12月の受験履歴 (リンク先は合格体験記)
- データアナリティクス専門知識
- SysOpsアドミニストレータアソシエイト
- セキュリティ専門知識 (今回)
勉強方法
今月3つ目の試験ですので、慣れてきたものです。まずはBlack Beltを読みます。あとは公式の模擬試験を解きました。BenchPrepってやつで、20問あります。前回受験後の1週間ぐらいかけて毎日夜に少しずつBlack Beltを読み、前日に模擬試験を解きました。模擬試験は解説もあるので、1問ずつ解いて、解説を読んで、分からない点は調べて、メモを残しながらです。
試験当日
65問170分。いつも通り試験中はだんだん眠くなってきて、集中力が途切れながらでした。一巡するのに130分かかり、残り40分でひととおり見直しました。8割ぐらい見直したところでタイムアップとなりました。
今月受けた3つの中では一番難しく感じました。半分以上の問題が自信なさげに答えて、一部の問題はまったくわからずに勘で答えているような状態でした。
数問は日本語の意味が読み解けず、英語の問題文や選択肢を読みました。
結果
スコア 875 でした。一番難しく感じた割にはスコアが高いです。これまでの8回の受験履歴の中でもかなり上位だと思います。偶然の正答が多かったのでしょうか。スコアの納得感は低いです。
所感
今回難しく感じたのは、勉強していた領域が試験範囲をカバーしきれてなかったのが理由だと思われます。ぜんぜんドキュメントを読む機会がなかったのに、試験で結構主役なサービスもありました。逆に詳しく理解したつもりのサービスが、「念のため試験にちょっと登場させたよ」ぐらいなものもありました。
3年後に再受験する自分に向けて、勉強しておくべき領域を勉強ノートとして残しておきます。
勉強ノート
Black Beltなどでは以下のカテゴリ分けがありますので、ここではそのカテゴリ分けに従います。
- ID・アクセス管理
- インフラ保護
- データ保護
- ログと監視
- インシデント対応
ID・アクセス管理
- IAM
- IAMユーザ
- アクセスキー
- IAMロール
- IAMポリシー
- MFA
- ポリシーでMFA必須にするConditionの書き方
"BoolIfExists": { "aws:MultiFactorAuthPresent": "true" }
- ポリシーでMFA必須にするConditionの書き方
- スイッチロール
- 信頼関係
- Permissions Boundary
- IAMユーザ
- AWS Directory Service
- 3種類のサービス
- AWS Managed Microsoft AD
- Simple AD
- AD Connector
- VPNやDirect Connectを組み合わせてオンプレ環境と連携することが多い
- 3種類のサービス
- AWS Organizations
- Organization Unit (OU、組織単位)
- 階層構造を持つ
- Service control policies (SCP)
- Organization Unit (OU、組織単位)
インフラ保護
- AWS WAF
- Web ACL
- マネージドルール
- SQLインジェクションなどよくある攻撃の対策
- カスタムルール
- IP制限
- レートベースルール
- 同一IPからの連続したアクセスの頻度を制限
- 特定の脆弱性に対するルール
- マネージドルール
- 設置場所
- CloudFront
- ALB
- API Gateway
- S3にアクセスログを保存できる
- Web ACL
- AWS Shield
- DDoS攻撃の対策のサービス
- AWS Shield Standard
- AWS上のリソースは自動で無償で保護されている
- AWS Shield Advanced
- 専門チームに攻撃対策を任せることができる
- DDoS攻撃によってリソースがオートスケールし、予期せぬ利用料が発生した場合、増加分の料金調整リクエストを行うことができる
- CloudFront
- 静的コンテンツおよび動的コンテンツを高速に配信するためのCDNサービス
- グローバルに展開されている
- オリジン(CloudFrontからリクエストを受けるところ)
- ELB
- EC2
- S3
- ユーザからの直接アクセスを防ぐためには、CloudFrontにオリジンアクセスアイデンティティ(OAI)を作成し、S3バケットポリシーにOAIからのみ読み取り可能と設定する
- S3にアクセスログを保存できる
- 静的コンテンツおよび動的コンテンツを高速に配信するためのCDNサービス
- ELB
-
AWSの3種類のLBの比較と使い分け (ALB, NLB, CLB) - Qiita
- 3種類あるんだなぐらいで大丈夫
- S3にアクセスログを保存できる
-
AWSの3種類のLBの比較と使い分け (ALB, NLB, CLB) - Qiita
- API Gateway
- 後ろにLambdaなどを連携させてAPIを公開するサービス
- ログは自動的にS3に保存される
- API Gatewayの前(ユーザ側)にAWS WAFやCloudFrontを組み合わせられる
- VPC
- サブネット
- ネットワークACL
- ステートレス
- セキュリティグループ
- ステートフル
- インターネットゲートウェイ
- NATゲートウェイ
- VPC Flow Logs
- S3にログを保存できる
- 送信元・送信先IPアドレス・ポート番号などが含まれる
- パケットの中身は含まれない
データ保護
- AWS KMS
- CMK
- 2種類
- カスタマー管理
- 1年での自動ローテーションを有効化できる
- AWS所有
- 3年で自動ローテーション
- カスタマー管理
- ローテーション
- ローテーション古いキー情報を保持しているため、古いキーで暗号化したデータはそのまま保持され、復元可能
- ローテーションすると、新しくデータを暗号化するものから新しいキーが利用される
- 手動ローテーション
- 1年というローテーション期間を変更したい場合は手動ローテーション
- key-idが変わるため、エイリアスを付けて、アプリケーション側はエイリアスで参照するようにして、新しいキーを参照できるようにする
- キーポリシー
- 2種類
- Envelope Encryption
- マスターキーをデータ暗号化に直接利用するのではなく、マスターキーで暗号化した暗号キーで対象データを暗号化・復号する
- 暗号化したデータとCMKで暗号化されたデータキーをいっしょに保管する
- 直接暗号化・復号できるのは4KBまで
- Envelope Encryption方式が推奨
- クライアントサイド暗号化とサーバサイド暗号化
- クライアントサイド暗号化
- 通信経路上も暗号化された状態になる
- サーバサイド暗号化
- 通信経路上は暗号化されない
- クライアントサイド暗号化
- リージョン間での鍵の共有は不可
- CMK
- EBS
- KMSで暗号化できる
- 暗号化されているEBSを接続しているEC2を起動するには、起動操作を行うIAMユーザがKMSへのアクセス権を持っている必要がある
- 暗号化されていない既存のEBSを暗号化するには
- スナップショットを取得
- スナップショットを暗号化を有効にしてコピー
- コピーしてできたスナップショットからEBSを作成
- EBSをEC2に接続
- RDS
- DBへの接続パスワードを保存する先は以下の2択
- Secrets Manager
- パスワードの自動ローテーションの機能がある
- Systems ManagerのParameter Store
- 無料
- Secrets Manager
- Secrets Managerにはパスワードの自動ローテーションの機能がある
- Systems ManagerのParameter Storeは無料
- DBへの接続パスワードを保存する先は以下の2択
- S3
- バケットポリシー
- VPCエンドポイント
ログと監視
- CloudWatch Logs
- EC2の中のアプリケーションが出力するログをCloudWatchに収集するには、CloudWatchエージェントをEC2にインストールすることが必要
- KinesisやElasticsearch (OpenSearch Service)に連携することで、ログのリアルタイム分析が可能
- AWS Config
- AWSのリソースの設定値やその変更履歴を自動収集するサービス
- 変更履歴や設定のスナップショットはS3に保存される
- 変更時にCloudWatch Eventsをトリガしたり、SNSで通知することが可能
- EC2やオンプレサーバの設定値を収集したい場合はSystems Managerにマネージドインスタンスとして登録する
- AWS Configは設定値の変更履歴が記録され、CloudTrailは変更のためのAPIコールが記録される
- CloudTrail
- AWS操作ログを収集するサービス
- ログは90日間保存できる
- S3に出力すれば長期保存できる
- 別AWSアカウントのS3バケットにも保存できる
- ダイジェストファイルを使ったログの整合性確認ができる
- Amazon Inspector
- アプリケーションのセキュリティを自動で診断するサービス
- EC2にエージェントを導入し、プラットフォームの脆弱性を診断するホスト型診断サービス
- EC2インスタンスのタグで対象となるインスタンスをグループ管理できる
- Systems Managerと組み合わせることで脆弱性発見後の対策の自動化が可能
インシデント対応
- AWS Config
- Config Ruleを設定するとルール非準拠が見つかったときにCloudWatch Eventsで通知可能
- ルールの例
- CloudTrailが有効
- 22番ポートが非公開
- S3バケットがパブリックになっていないこと
- EBSが暗号化されていること
- ルールの例
- ルール非準拠を検知したタイミングで自動修復も可能
- Config Rule → CloudWatch Events → Lambdaで修復
- Config Rule → Systems Manager Automation
- Config Ruleを設定するとルール非準拠が見つかったときにCloudWatch Eventsで通知可能
- AWS Systems Manager
- 略称はSSM
- サーバにSSMエージェントをインストールする必要がある
- Session Manager
- Security Group不要、SSHキーも不要で、サーバにSSHやPowerShellで接続可能
- Run Command
- 複数のサーバに一括でコマンドを実行できる機能
- Automation
- Automation DocumentというJSONまたはYAML形式で処理を記述し、実行できる
- Inventory
- サーバ上のソフトウェア一覧を表示
- Patch Manager
- パッチの適用状況の確認と自動適用
- Parameter Store
- パスワードやその他の文字列パラメータを保存できる機能
- EC2に限らず、Lambdaなどからもよく使われる
- CloudWatch
- ClodWatch Alarms
- アラームが発生したらSNSへの通知やLambdaの起動ができる
- CloudWatch Events
- イベントに応じてSNSへの通知やLambdaの起動などができる
- cron形式でのイベント
- 他のサービスで発生するイベント
- CloudTrail
- Trusted Advisor
- Trusted Advisor自体がバージニアリージョンで動いているため、バージニアリージョンに切り替えないと設定できない
- Macie
- GuardDuty
- Security Hub
- イベントに応じてSNSへの通知やLambdaの起動などができる
- ClodWatch Alarms
- SNS
- 通知する手段
- メール
- Lambda起動
- など
- 通知する手段
- Trusted Advisor
- コスト、パフォーマンス、セキュリティなどの観点でチェックしてくれるサービス
- us-east-1バージニアリージョンで動いているサービス
- セキュリティの項目例
- 無制限アクセスのセキュリティグループ
- CloudTrailが有効になっているかどうか
- IAMパスワードポリシー
- IAMアクセスキーのローテーション
- Amazon Macie
- S3バケットに個人情報が保存されているかを調査するサービス
- 自然言語処理が中で使われて入る
- 検知したらCloudWatch Eventsに通知できる
- GuardDuty
- セキュリティの観点から脅威リスクを検知、可視化し、通知するサービス
- 検知したらCloudWatch Eventsに通知できる
- 検知するためのソースは以下の3種類
- CloudTrailのログ
- VPC Flow Logs
- DNS Logs
- AWS Security Hub
- PCI DSSなど業界標準やベストプラクティスに基づいたチェック
- 以下のサービスと連携し、ハブのように動く
- GuardDuty
- Amazon Inspector
- Macie
- IAM Access Analyzer
- AWS Firewall Manager
- AWS Systems Manager Patch Manager
- AWS Config
- 3rd Partyのセキュリティ製品
- 不審なEC2インスタンスを検知したときの対応
- 該当インスタンスへの管理者以外からのアクセスをセキュリティグループ設定により切り離し
- これによりELBや他のインスタンスとの通信を遮断
- AutoScalingグループに所属している場合は、停止時に削除されてしまう可能性があるため、AutoScalingグループからのデタッチが必要
- 該当インスタンスへの管理者以外からのアクセスをセキュリティグループ設定により切り離し
- EC2キーペア流出時の対応
- Systems Manager Run Commandにより全EC2インスタンスでキーのリセット
- AWS が所有するIPアドレスからDoS攻撃などを受けたとき
- AWS abuseの窓口に通報