こんにちは。
今回は、 AWS 認定 セキュリティ 専門知識のサンプル問題解説です。
AWS クラウドを扱う上で重要になってくるセキュリティについての認定試験です。
AWS 認定とは
AWS 認定は、クラウドの専門知識を検証し、専門家が需要の高いスキルを強調し、組織が AWS を使用してクラウドイニシアチブにおける効果的で革新的なチームを構築するのに役立ちます。個人やチームが独自の目標を達成できるように、役割と専門分野ごとに設計したさまざまな認定試験から選択します。
AWS 認定は領域やレベルごとに分けられ、本校執筆時点(2021/1)では12の認定資格が存在しています。
- レベル
- 基礎
- アソシエイト(中級ととらえてください)
- プロフェッショナル(上級ととらえてください)
- 専門知識(対象分野に特化した高度な認定)
- 領域
- 全般
- ソリューション
- 開発
- 運用
- DBや機械学習といった専門分野
表にまとめると以下の通りです。
# | レベル | 認定名 |
---|---|---|
1 | 基礎 | クラウドプラクティショナー |
2 | アソシエイト | ソリューションアーキテクト アソシエイト |
3 | アソシエイト | デベロッパー アソシエイト |
4 | アソシエイト | SysOps アドミニストレーター アソシエイト |
5 | プロフェッショナル | ソシューションアーキテクト プロフェッショナル |
6 | プロフェッショナル | DevOps エンジニア プロフェッショナル |
7 | 専門知識 | 高度なネットワーク |
8 | 専門知識 | セキュリティ |
9 | 専門知識 | 機械学習 |
10 | 専門知識 | データ分析 |
11 | 専門知識 | データベース |
AWS 認定 セキュリティ専門知識
試験の概要や出題割合などは、以下の試験ガイドをご確認ください。
https://d1.awsstatic.com/ja_JP/training-and-certification/docs-security-spec/AWS-Certified-Security-Specialty_Exam-Guide.pdf
サンプル問題を解いてみよう
それでは、サンプル問題を確認していきましょう。
※以降、Markdown 記法に合わせて、サンプル問題の ABCD を 1234 と置き換えています。
第1問
問題文
ある企業が社内クラウドセキュリティポリシーにおいて、社内の VPC ~ KMS 間の通信はすべて AWS 内で行い、パブリックサービスエンドポイントを使用してはならないと定めています。
最も確実にこの要件を満たすには、どうすればよいですか (2 つ選択してください)。
- aws:sourceVpce 条件を、社内の VPC エンドポイント ID を参照している AWS KMS キーポリシーに追加する。
- VPC インターネットゲートウェイを VPC から削除し、仮想プライベートゲートウェイを VPC に追加することにより、パブリックインターネットに直接接続できないようにする。
- AWS KMS に対する VPC エンドポイントを作成し、プライベート DNS を有効化する。
- KMS のキーインポート機能を使用して、AWS KMS キーを VPN 上でセキュアに転送する。
- "aws:SourceIp": "10.0.0.0/16" 条件を AWS KMS キーポリシーに追加する。
回答
1,3
解説
AWS の各種サービスのエンドポイントはインターネットに公開されていますが、プライベートな Amazon VPC 内からインターネットに出ないでアクセスできるように、VPC エンドポイントというものを用意しています。
この問題では、インターネットへ通信を出さずに AWS KMS を利用するにはどうしたらよいのか?をたずねているものです。
- **適当であると考えます。**ポリシーの条件として「aws:sourceVpce」を用いて、対象の VPC エンドポイントの ID を指定することで該当する VPC エンドポイントからの通信のみに限定することが可能です。
- 不適当です。インターネットゲートウェイを削除すれば Amazon VPC 内のリソースは確かにインターネットに出られなくはなりますが、それだけでは AWS KMS の利用ができなくなってしまいます。
- **適当であると考えます。**AWS KMS は VPC エンドポイントに対応しているサービスです。VPC エンドポイントを利用することでインターネットへ通信を出すことなく、AWS KMS を利用できます。また、VPC エンドポイントを利用するには、Amazon VPC の設定でプライベート DNS (DNS 解決、DNS ホスト名)を有効化する必要があります。
- 不適当です。キーインポート機能とパブリックサービスエンドポイントを使わないことは関係ありません。
- 不適当です。このポリシーの内容自体は、指定したプライベート IP アドレス範囲からのアクセスしか認めないものですが、アクセス元である側がパブリックサービスエンドポイントを使わなくなるものではありません。
第2問
問題文
アプリケーションチームが、2 個のアプリケーションを使用するソリューションを設計しています。セキュリティチームは、アプリケーションのログを 2 か所に分けて格納したいと考えています。一方のアプリケーションでは、機密データを含むログが生成されるからです。
リスクと作業量を最小限に抑えつつ、これらの要件を満たすには、どうすればよいですか。
- Amazon CloudWatch Logs を使用して、すべてのログを取得する。ログファイルを解析するための AWS Lambda 関数を作成する。機密データを別のログに移動する。
- Amazon CloudWatch Logs を使用し、ロググループを 2 個作成する。それぞれのロググループを各アプリケーション用として使用する。必要に応じて、AWS IAM ポリシーを使用して、ロググループに対するアクセスを制御する。
- 各ログを 1 個のファイルにまとめる。Amazon CloudWatch Logs を使用する。CloudWatch メトリクスフィルタを 2 個作成し、ログから機密データを除去する。
- 機密データを含むログを Amazon EC2 インスタンスのローカルストレージに格納するロジックをアプリケーションに追加する。Amazon EC2 インスタンスにログインし、機密データを含むログをセキュアな場所に移動するバッチスクリプトを作成する。
回答
2
解説
アプリケーションログを2か所に分けて格納したいし、機密データがあるのでアクセスできる権限を絞りたいといったニーズに対して、どう対処したらよいかを尋ねています。また、この作業にあたっての工数も少なくしたいというものです。
- 不適当です。Amazon CloudWatch Logs を使うことはよいのですが、ログ解析に AWS Lambda 関数を開発するとあるため、作業量が最小限に収まりません。
- **適当であると考えます。**Amazon CloudWatch Logs はロググループと呼ばれる単位でログが格納可能です。また、IAM ポリシーでアクセス可能なロググループを制御することで機密データへのリスクも抑えられます。
- 不適当です。2つのアプリケーションのログを1個のファイルにまとめる作りこみや、メトリクスフィルタの設定など作業工数が最小限に収まりませんし、ログから機密データを除去したら、機密データにアクセスすべき人の要件を満たせません。※そもそもメトリクスフィルタは、例えばログ内のキーワードをカウントして、単位時間内のエラー件数何件あったなどを抽出することに使います。
- 不適当です。このアプリケーションがどんな AWS サービスで動いているのかわかりませんが(Amazon EC2?AWS Lambda?)、新たにロジックをアプリケーションに追加する工数や、ログをセキュアな場所に移動するためのバッチスクリプトの開発にかかる工数は、どう考えても最小限に収まりません。
第3問
問題文
セキュリティエンジニアが、3 層アプリケーションに対するセキュリティグループルールを設定する必要があります。
- プレゼンテーション層 — Web 上でユーザーによってアクセスされます。セキュリティグループ presentation-sg によって保護されます。
- ロジック層 — RESTful API。プレゼンテーション層から HTTPS を使用してアクセスされます。セキュリティグループ logic-sg によって保護されます。
- データ層 — SQL Server データベース。ロジック層からポート 1433 経由でアクセスされます。セキュリティグループ data-sg によって保護されます。
アプリケーションのセキュリティと機能を確保するには、セキュリティグループルールをどのように設定すればよい
ですか (3 つ選択してください)。
- presentation-sg: 0.0.0.0/0 からのポート 80 および 443 経由でのアクセスを許可する。
- data-sg: presentation-sg からのポート 1433 経由でのアクセスを許可する。
- data-sg: logic-sg からのポート 1433 経由でのアクセスを許可する。
- presentation-sg: data-sg からのポート 1433 経由でのアクセスを許可する。
- logic-sg: presentation-sg からのポート 443 経由でのアクセスを許可する。
- logic-sg: 0.0.0.0/0 からのポート 433 経由でのアクセスを許可する。
回答
1,3,5
解説
Web 3層構成のごく一般的な構成を組む際のセキュリティグループの設定はどれかというものです。問題文から構成図を簡単に起こすと以下の様になります。
また、セキュリティグループはステートフルな通信許可を行いますので、戻りの通信のことを考える必要ありません。
以上をもとに、選択肢から回答を導き出していきます。本番の試験の際も、書き込みができるシートが貸与されるのでこのように構成図を書いて考えるのもおすすめです!
- **適当であると考えます。**0.0.0.0/0 はすべての発信元を指し示すものなので、例えばインターネットからのアクセスも許可されます。問題文や上図にあるとおり、0.0.0.0/0からプレゼンテーション層の 80 と 443 ポートへのアクセス許可がされています。
- 不適当です。問題文や上図にある通り、プレゼンテーション層からデータ層へのアクセスは要件にありません。
- **適当であると考えます。**問題文や上図にあるとおり、ロジック層からデータ層の 1443 ポートへのアクセス許可がされています。
- 不適当です。問題文や上図にある通り、データ層からプレゼンテーション層へのアクセスは要件にありません。
- **適当であると考えます。**問題文や上図にあるとおり、プレゼンテーション層からロジック層の HTTPS(443) ポートへのアクセス許可がされています。
- 不適当です。問題文や上図にある通り、0.0.0.0/0 からロジック層へのアクセスは要件にありません。
第4問
問題文
セキュリティエンジニアが、AWS 上で Web アプリケーションを開発している製品チームと共同作業を行っています。このアプリケーションでは、Amazon S3 を使用して静的コンテンツをホストし、Amazon API Gateway を使用して RESTful サービスを提供し、Amazon DynamoDB をバックエンドデータストアとして使用します。ユーザーは既に、SAML ID プロバイダを通じて公開されているディレクトリに登録されています。
ユーザーが認証を受けてこの Web アプリケーションにアクセスし、API を呼び出せるようにするには、セキュリティエンジニアはどうすればよいですか (3 つ選択してください)。
- AWS Lambda を使用して、カスタム承認サービスを作成する。
- Amazon Cognito で、属性を Amazon Cognito ユーザープール属性にマッピングするよう、SAML ID プロバイダを構成する。
- Amazon Cognito ユーザープールを証明書利用者として追加するよう、SAML ID プロバイダを構成する。
- ソーシャルログインプロバイダと統合するよう、Amazon Cognito ID プールを構成する。
- ユーザーの E メールアドレスとパスワードを格納するよう、DynamoDB を更新する。
- Amazon Cognito ユーザープールオーソライザーを使用するよう、API Gateway を更新する。
回答
2,3,6
解説
API Gateway を使った Restful サービスにユーザー認証を付けるにはどうしたらよいか?という問題です。この環境ではすでにユーザー情報が SAML ID プロバイダを通じて公開されているディレクトリに登録されているとのことなので、 SAML ID プロバイダと連携して認証が行えるサービスを組み合わせれば答えが導き出せます。
- 不適当です。API Gateway のオーソライザーとして Lambda オーソライザーを指定し承認サービスを作成すればできなくもないですが、この問題としては適しません。
- **適当であると考えます。**SAML 属性名と送信先ユーザープール属性のマッピングを行う必要があります。
- **適当であると考えます。**Amazon Cognito ユーザープールと SAML IDプロバイダを連携するには、SAML ID プロバイダで Amazon Cognito を証明書利用者として登録する必要があります。
- 不適当です。ソーシャルログインプロバイダは、Twitter や Amazon といった IDプロバイダを利用するもので、 SAML ID プロバイダが用意されている本環境では適しません。
- 不適当です。SAML ID プロバイダを通じて公開されているディレクトリにユーザーが登録されているので、E メールアドレスやパスワードを DynamoDB に格納する必要はありません。
- **適当であると考えます。**API Gateway のアクセス制御では、Amazon Cognito ユーザープールをオーソライザーとして指定ができます。Lambda オーソライザーも指定可能ですが、他の選択肢を見るに、Amazon Cognito が正しいと考えます。
第5問
問題文
ある企業が、AWS 上で Web アプリケーションをホストしており、また Amazon S3 バケットを使用して画像を格納しています。各ユーザーがバケット内のオブジェクトを読み取れるようにする必要があります。セキュリティエンジニアが、パブリック読み取りアクセスを許可する次のバケットポリシーを作成しました。
{
"ID":"Policy1502987489630",
"Version":"2012-10-17",
"Statement":[
{
"Sid":"Stmt1502987487640",
"Action":[
"s3:GetObject",
"s3:GetObjectVersion"
],
"Effect":"Allow",
"Resource":"arn:aws:s3:::appbucket",
"Principal":"*"
}
]
}
しかし、オブジェクトを読み取ろうとすると、"Action does not apply to any resource(s) in statement." というエラーが通知されます。
このエラーを解消するには、どうすればよいですか。
- PutBucketPolicy 権限を適用することによって、IAM 権限を変更する。
- ポリシー名がバケット名と同じであるかどうかを調べる。同じでない場合、ポリシーをバケットと同じ名前にする。
- resource セクションを "arn:aws:s3:::appbucket/*" に変更する。
- s3:ListBucket アクションを追加する。
回答
3
解説
この問題は、権限設定ができているようなのにどこか足りていないため意図した通りに動かない!どうしたらよい?というものです。期待する動作は、オブジェクトを読み取ることに成功することです。ポリシー内の許可されているリソースに着目すると答えが導けます。
- 不適当です。
PutBucketPolicy
の IAM 権限を持つようになったとしても、バケットポリシーそのものに変更がなければオブジェクトの読み取りはできません。 - 不適当です。ポリシー名とバケット名が同じである必要はありません。
- **適当であると考えます。**オブジェクトにアクセスしたい場合、resource セクションで指定しているバケット名の末尾に
/*
を付与する必要があります。 - 不適当です。
s3:ListBucket
アクションはアクセス権限があるバケットのリストを得られるものです。オブジェクトの読み取りには効果がありません。
第6問
問題文
ある企業が、ある VPC 内にデータベースホストを配置し、アプリケーション層と Web 層が配置されている別の VPC に対する VPC ピアリングを構成することを決めました。しかし、アプリケーションサーバーからデータベースに接続できません。
この問題を解決するには、どうすればよいですか (2 つ選択してください)。
- アプリケーションサーバーがプライベートサブネットとパブリックサブネットのどちらに配置されているかを確認する。
- アプリケーションサーバーサブネットに対するルーティングテーブルを調べ、VPC ピアリング接続へのルートが設定されているかどうかを確認する。
- データベースサブネットに対する NACL を調べ、インターネットからのトラフィックを許可するルールが設定されているかどうかを確認する。
- データベースセキュリティグループを調べ、アプリケーションサーバーからのトラフィックを許可するルールが設定されているかどうかを確認する。
- データベース VPC 内にインターネットゲートウェイがあるかどうかを確認する。
回答
2,4
解説
データベースが稼働している VPC とアプリケーションや Web サーバーが稼働している VPC をピアリング接続をしたが通信できないというケースをどう対処したらよいか?という問題です。
- 不適当です。パブリックサブネットとプライベートサブネットどちらに配置されているかと、通信できない件は関係ありません。
- **適当であると考えます。**VPC ピアリング接続を行う場合は、対向の VPC への通信経路をルーティングテーブルで指定する必要があります。
- 不適当です。NACL の設定が適当ではない場合もありますが、インターネットからのトラフィックの許可有無と VPC ピアリング接続をしての通信については関係がありません。
- **適当であると考えます。**データベースサーバにアタッチしているセキュリティグループにアプリケーションサーバーからの通信を許可する設定を入れないと通信が行えません。
- 不適当です。データベース VPC 内にインターネットゲートウェイが存在していようがいまいが、VPC ピアリング接続をした先の VPC との通信ができないことに関係はありません。
第7問
問題文
Amazon DynamoDB テーブルから項目を取得する新しい AWS Lambda 関数をセキュリティエンジニアがテストした際、この関数がデータを Amazon CloudWatch Logs にロギングしていないことに気付きました。
この Lambda 関数によって代行されるロールに、次のポリシーが割り当てられていました。
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"Dynamo-1234567",
"Action":[
"dynamodb:GetItem"
],
"Effect":"Allow",
"Resource":"*"
}
]
}
この関数が適切にロギングできるようにするには、どの最小権限ポリシーを追加すればよいですか。
1.
{
"Sid":"Logging-12345",
"Resource":"*",
"Action":[
"logs:*"
],
"Effect":"Allow"
}
2.
{
"Sid":"Logging-12345",
"Resource":"*",
"Action":[
"logs:CreateLogStream"
],
"Effect":"Allow"
}
3.
{
"Sid":"Logging-12345",
"Resource":"*",
"Action":[
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Effect":"Allow"
}
4.
{
"Sid":"Logging-12345",
"Resource":"*",
"Action":[
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:DeleteLogGroup",
"logs:DeleteLogStream",
"logs:getLogEvents",
"logs:PutLogEvents"
],
"Effect":"Allow"
}
回答
3
解説
AWS Lambda 関数に割り当てられている IAM ロールの内容が不足しており、 Amazon CloudWatch Logs へログを配信できないため、どうポリシーを追記したらよいかを尋ねている問題です。また、追記する際は最小権限の原則に則ってセキュリティ的にも問題ない設定をする必要があります。
- 不適当です。
logs:*
を使えば確かにログ配信が行えるようになりますが不要な権限まで付与していますので、最小権限の原則から外れてしまいます。 - 不適当です。
logs:CreateLogStreams
では、ログストリームの作成は行えますが実際のログ書き込みが行えません。 - **適当であると考えます。**ログを配信するのであれば、選択肢の通り、
logs:CreateLogGroup
,logs:CreateLogStream
,logs:PutLogEvents
があれば十分です。 - 不適当です。この設定でもログ配信は行えますが、
logs:DeleteGroup
など不要な権限も付与されているので最小権限の原則から外れてしまいます。
第8問
問題文
ある企業が、Amazon S3 上にデータレイクを作成しようとしています。データは、機密データを含む数百万個の小規模ファイルから成ります。セキュリティチームは、このアーキテクチャに対して次の要件を定めています。
- 送信中データを暗号化しなければならない。
- 格納データを暗号化しなければならない。
- バケットはプライベートでなければならない。バケットが誤ってパブリックになった場合、データは機密扱いのままでなければならない。
これらの要件を満たすには、どうすればよいですか (2 つ選択してください)。
- Amazon S3 バケットに対して AES-256 暗号化方式を有効化する。「Amazon S3 で管理されるキーを使用したサーバー側暗号化」(SSE-S3) を使用する。
- S3 バケットに対してデフォルトの暗号化方式を有効化する。「AWS KMS で管理されるキーを使用したサーバー側暗号化」(SSE-KMS) を使用する。
- PutObject リクエストの中に aws:SecureTransport が含まれていない場合に拒否するバケットポリシーを追加する。
- aws:SourceIp を使用して、社内イントラネットからのアップロードとダウンロードだけを許可するバケットポリシーを追加する。
- Amazon Macie を有効化して、データレイクの S3 バケットを監視し、バケットに変更が加えられた場合に対処する。
回答
2,3
解説
Amazon S3 バケットの暗号化とデータを格納する際の経路がプライベートになるように設定するにはどうしたらよいか?という問題です。
- 不適当です。
SSE-S3
を用いて暗号化することはできますが、暗号化されたか、複合化されたかといった事象が CloudTrail で証跡として残りません。また、AWS KMS キーは利用できるユーザーを設定できるので、もし、バケットがパブリックになった場合にも外部からの復号化ができないため、SSE-KMS
のほうがよいと考えます。 - **適当であると考えます。**上述の通り、
SSE-KMS
を用いれば、暗号化に加えて、バケットが誤ってパブリックになった場合もデータは機密扱いのままにできます。 -
適当であると考えます。
PutObject
つまり、オブジェクトを格納する際に、SecureTransport(セキュアな通信)で行われているかを判定する設定です。この設定を入れることで非暗号化通信は拒否されるので、送信中データを暗号化しなければならない
という要件を満たせます。 - 不適当です。この設定を入れることでプライベートな範囲でのデータアクセスにはなりますが、通信の暗号化といった観点を満たせません。
- 不適当です。Amazon Macie は Amazon S3 バケット内のデータを走査して機密データの有無を確認するサービスですが暗号化やバケットが誤ってパブリックになった場合にデータを機密扱いのままにするといった効果はありません。あくまで格納されたデータが機密であればアラートをあげてくれるというものです。
第9問
問題文
セキュリティエンジニアが、すべての企業アカウントにおけるすべての API 呼び出しが収集されていること、および API 呼び出しがオンライン状態でありすぐに 90 日間分析できることを確認する必要があります。コンプライアンス上の理由により、このデータは 7 年間復元可能でなければなりません。
拡張性と費用対効果の高い方法でこのデータ保持要件を満たすには、どうすればよいですか。
- すべてのアカウントにおいて AWS CloudTrail ロギングを有効化し、バージョニングが有効化されている中央の Amazon S3 バケットにログを格納する。データを毎日 Amazon Glacier に移動し、90 日後にデータを失効させるライフサイクルポリシーを作成する。
- すべてのアカウントにおいて AWS CloudTrail ロギングを有効化し、S3 バケットにログを格納する。7 年後に各バケット内のデータを失効させるライフサイクルポリシーを作成する。
- すべてのアカウントにおいて AWS CloudTrail ロギングを有効化し、Amazon Glacier にログを格納する。7年後にデータを失効させるライフサイクルポリシーを作成する。
- すべてのアカウントにおいて AWS CloudTrail ロギングを有効化し、中央の Amazon S3 バケットにログを格納する。90 日経過したデータを Amazon Glacier に移動し、7 年後にデータを失効させるライフサイクルポリシーを作成する。
回答
4
解説で
API 呼び出しを記録するサービスは、 AWS CloudTrail です。その証跡(ログ)は Amazon S3 に保存できます。また、拡張性と費用対効果が高いものと要件にかかれているので、簡単に Amazon S3 の料金を安く抑えて長期保存を行うにはどうしたらよいか?という問題です。
- 不適当です。Amazon Glacier は Amazon S3 と比較したら安価ですが取り出しに時間がかかります。そのため
すぐに90 日間分析できることを確認する必要があります
という要件を満たせません。また、90 日後にデータを失効させてしまったら、このデータは 7 年間復元可能でなければなりません。
という要件も満たせません。 - 不適当です。ぱっと見よさそうですが、すぐに分析が必要な90日を経過したら、ストレージクラスを Amazon Glacier にすることで費用対効果をあげることができます。
- 不適当です。ログの格納先として指定できるのは、Amazon S3 のバケットです。仮にライフサイクルルールで 0 日後に ストレージクラスを Amazon Glacier にすることを表現していたとしても、
すぐに 90 日間分析できることを確認する必要があります。
という要件を満たせません。 - **適当であると考えます。**90日間は即座に分析が可能で、それ以降はストレージクラスを Amazon Glacier に移行することで費用対効果をあげることができます。
第10問
問題文
セキュリティエンジニアが、「あるユーザーのアクセスキーが GitHub 上で見つかった」という通知を受けました。セキュリティエンジニアは、このアクセスキーを使い続けることができないようにする必要があります。また、このアクセスキーが不正行為に使用されたかどうかを調べる必要があります。
これらのタスクを実行するには、どうすればよいですか。
- このユーザーの IAM 権限を確認し、未承認リソースがあれば削除する。
- このユーザーを削除する。すべてのリージョンにおける Amazon CloudWatch Logs を確認する。アクセスキーが不正使用されていた場合、報告する。
- このユーザーのアクセスキーを削除またはローテートする。すべてのリージョンにおける AWS CloudTrail ログを確認する。未承認リソースがあれば削除する。
- GitHub の投稿からアクセスキーを削除するよう、このユーザーに指示する。キーをローテートする。起動されたインスタンスがある場合、再展開する。
回答
3
解説
ソースコード内にテスト用などでハードコーディングしていたアクセスキーの存在を忘れて、GitHub のパブリックなリポジトリにプッシュしてしまった場合の対処方法はどれか?という問題です。
実際、こういったケースは多く、悪意のあるユーザーがアクセスキーが格納されたリポジトリが無いか虎視眈々と走査し、見つけ次第、暗号通貨のマイニングやボットネットワークの構築といった目的で高価で高性能な EC2 インスタンスを何台も起動し続けます。
- 不適当です。未承認リソースの削除だけでは、アクセスキーを使い続けることができてしまい、問題の解決にはなりません。
- 不適当です。ユーザーを削除するのは最後の手段です。アクセスキーが不正に使用されているかは Amazon CloudWatch Logs ではなく、AWS CloudTrailで確認します。
- **適当であると考えます。**アクセスキーの削除もしくはローテートをすることで、流出したキーは使用不可になります。また、AWS CloudTrail で流出したキーで RunInstances などの操作を行っていないかを確認することで、未承認操作が行われているかがわかります。もちろん、EC2 のマネージメントコンソールを見ればわかるかもしれませんが、AWS CloudTrail であればサービスを横断で確認が可能です。
- 不適当です。GitHub 上から削除し、キーのローテートも正しいですが、インスタンスを再展開してはならないです。未承認のインスタンスは即刻終了させる必要があります。
サンプル問題以外の学習リソース
様々な学習リソースが用意されています。
以下はその一例です。
- AWS 公式の模擬問題
- AWS 認定サイトから受験可能です。
- 市販の試験対策本(おすすめ!)
- 要点整理から攻略する『AWS認定 セキュリティ-専門知識』
まとめ
繰り返しになりますが、このセキュリティ専門知識は、AWS クラウドを扱う上で重要になってくるセキュリティについての認定試験です。
守るべきデータや守るべきリソースは何かを特定し、重要度や優先度、コストなど様々な観点から最善のセキュリティ対策を施していくために必要な知識を確認することができます。
わたし自身、この記事を執筆する直前に本認定試験を受験し、合格しました。この勉強を通じて、セキュリティ対策の方法、重要性について再認識できたと感じています。
記載されている会社名、製品名、サービス名、ロゴ等は各社の商標または登録商標です。