AWS クラウドプラクティショナー セキュリティとコンプライアンス 問題

正解は「利用者が自分で設定して管理する」です。Amazon EC2 の文書は、利用者の責任 (クラウドの中のセキュリティ) として、VPC やセキュリティグループの設定でインスタンスへのネットワークの出入りを管理することを挙げています。どのポートをだれに開けるかは使い方で変わるので、AWS は決めません。「AWS が利用者に代わって最適な設定を保つ」は誤りで、AWS は仕組みを用意するだけです。「AWS が設定し、利用者は中身を変えられない」も誤りで、ルールは利用者が自由に足したり消したりします。「利用者が頼むと AWS のサポートが代わりに設定する」も誤りで、サポートは相談の窓口であり、設定の責任が利用者にあることは変わりません。出典 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-⁠security.html

正解は「利用者が選んだサービスの上の設定とデータを守ること」です。AWS の責任共有モデルの頁は、利用者の責任を「クラウドの中のセキュリティ」と呼び、その範囲は利用者が選ぶサービスで決まり、利用者が行う設定の量もそれで変わると説明しています。一方、AWS の責任は「クラウドのセキュリティ」で、サービスを動かすハードウェア、ソフトウェア、ネットワーク、施設を守ることです。「建物と設備を守ること」は AWS 側の「クラウドのセキュリティ」に当たります。「利用者が AWS の機器と回線の故障に備えること」も誤りで、機器と回線は AWS が守る範囲であり、利用者の受け持ちではありません。「第三者の監査に通すこと」も、AWS が自社の基盤について受けるもので、利用者の受け持ちではありません。出典 https://aws.amazon.com/compliance/shared-⁠responsibility-⁠model/

正解は「遅い SQL の問い合わせを見直して速くする」です。Amazon RDS の文書は、オンプレミス、EC2、RDS の受け持ちを表で比べています。RDS ではデータベースのソフトのパッチ、バックアップ、OS のインストールやパッチは AWS の受け持ちになりますが、アプリに合わせた最適化は RDS でも利用者に残ります。文書は、SQL の問い合わせを調整して性能を上げること (クエリのチューニング) は利用者の責任だとはっきり書いています。「ソフトにパッチを当てる」「バックアップの仕組みを作る」「OS をインストールする」は、EC2 に自分で入れていたときは学校の仕事でしたが、RDS に移すと AWS が受け持つ仕事に変わります。出典 https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html

正解は「AWS が更新した版を作り、既存の関数にも当てる」です。AWS Lambda の文書は、マネージドランタイムのセキュリティの更新を用意して公開するのは Lambda (AWS) の責任だとしています。さらに更新の設定が Auto のときは、既存の関数への更新の適用も Lambda が受け持ちます。EC2 なら利用者が OS にパッチを当てますが、Lambda ではこの部分が AWS 側へ移ります。「利用者が実行環境へ入って当てる」は誤りで、利用者は実行環境に入って作業しません。「手動で更新の作業を予約する」は Auto のときには要りません。「作り直さない限り当たらない」は Auto ではない設定や、コンテナイメージで配る場合の話で、この場面には当たりません。出典 https://docs.aws.amazon.com/lambda/latest/dg/runtime-⁠management-⁠shared.html

正解は「Amazon EC2」です。AWS の責任共有モデルの頁は、Amazon EC2 を IaaS (サーバーの土台を借りる形) に分け、利用者が必要なセキュリティの設定と管理をすべて行うと説明しています。具体的には、ゲスト OS の更新とパッチ、利用者が入れたアプリ、セキュリティグループの設定が利用者の受け持ちです。同じ頁は、Amazon S3 や Amazon DynamoDB のような抽象化されたサービスでは、土台、OS、プラットフォームを AWS が動かし、利用者は主にデータと権限を管理すると書いています。AWS Lambda もサーバーや OS を利用者が管理しないサービスで、利用者の受け持ちはコードや設定が中心になり、EC2 より狭くなります。出典 https://aws.amazon.com/compliance/shared-⁠responsibility-⁠model/

正解は「データの暗号化の選択肢を決めて管理すること」です。AWS の責任共有モデルの頁は、Amazon S3 や Amazon DynamoDB のような抽象化されたサービスでは、AWS が土台の層、OS、プラットフォームを動かすと説明しています。そのうえで利用者は、暗号化の選択肢を含めて自分のデータを管理し、資産を分類し、IAM で適切な権限を付ける責任を持つと書いています。「サーバーの OS を保守すること」と「土台のソフトウェアの更新を自分で当てること」は、抽象化されたサービスでは AWS が受け持つ部分です。「機器を予備と入れ替えること」もハードウェアの話なので、AWS 側の「クラウドのセキュリティ」に入ります。出典 https://aws.amazon.com/compliance/shared-⁠responsibility-⁠model/

正解は「従業員へのセキュリティの教育と訓練」です。AWS の責任共有モデルの頁は、共有される統制の例として、パッチの管理、構成の管理、意識の向上と訓練を挙げています。訓練については、AWS は AWS の社員を訓練し、利用者は自社の社員を訓練しなければならない、と説明しています。「データの機密度の分類」は、利用者が自分の資産として行う仕事で、AWS が受け持つ部分はありません。「データを決めた区画に分けて流す統制」は、同じ頁で利用者だけの責任 (Customer Specific) の例として挙げられています。「機器の故障の修理」は、サービスを動かす基盤の話なので AWS だけの受け持ちです。出典 https://aws.amazon.com/compliance/shared-⁠responsibility-⁠model/

正解は「組織と業務に当てはまる法令や規制」です。AWS の責任共有モデルの頁は、利用者の責任は多くの要因で変わると説明し、その要因として、選ぶ AWS のサービスとリージョン、それらのサービスを自社の IT の環境にどう組み込むか、組織と業務に当てはまる法令や規制を挙げています。たとえば個人情報を扱う業界の会社は、同じサービスを使っても、法令に合わせて追加の管理が求められます。「サポートプランの種類」は、受けられる支援の手厚さが変わるだけで、セキュリティの責任の範囲は変わりません。「利用を始めてからの年数」も、責任の分け方とは関係がありません。「料金の支払いに使う方法」は請求の話で、責任の範囲を左右しません。出典 https://aws.amazon.com/compliance/shared-⁠responsibility-⁠model/

正解は「AWS が決めた手順で、管理の下のまま消去し処分する」です。AWS のデータセンターの統制の頁は、利用者のデータを置く記憶装置を重要な物として扱い、寿命を迎えたら NIST 8⁠0⁠0-⁠8⁠8 という基準の手法で廃棄すると説明しています。さらに、安全に処分し終えるまで、その記憶装置は AWS の管理の外へ出さないと書いています。これは物理の守りなので、AWS の受け持ちです。「手元に送られる」は誤りで、記憶装置は AWS の管理の下から出ません。「利用者が自分で上書きの消去をする」も誤りで、利用者は物理の装置に触れません。「再販の業者へ引き渡される」は、管理の外へ出さないという説明と合いません。出典 https://aws.amazon.com/compliance/data-⁠center/controls/

正解は「アクセスの権限を決めて管理する利用者」です。Amazon S3 の文書は、S3 での利用者の責任として、データの管理、資産の分類、IAM ロールなどの設定でデータへのアクセスを管理し適切な権限を付けることを挙げています。だれが読めるかを決めるのは利用者の仕事です。「既定の暗号化を受け持っている AWS」は誤りで、保存時の暗号化はディスク上のデータを守る物であり、読む権限を持つ相手には中身が渡ります。権限の設定の誤りは暗号化では防げません。「リージョンの AWS の担当者」も誤りで、AWS の担当者が利用者の権限の設定を決めることはありません。「第三者の監査人」は AWS の基盤を検証する立場で、利用者の設定の責任は負いません。出典 https://docs.aws.amazon.com/AmazonS3/latest/userguide/security.html

正解は「AWS Artifact」です。AWS Artifact の文書は、AWS のセキュリティとコンプライアンスの文書を必要なときにダウンロードできるサービスだと説明しています。例として、ISO の基準や PCI の基準への準拠の報告書、SOC レポートが挙げられています。監査の担当者は、ここで取った報告書を自社の監査の証拠に使えます。「AWS Trusted Advisor」は、利用者のアカウントの設定を見てコストやセキュリティの改善を勧めるサービスで、監査の報告書は配りません。「AWS Health Dashboard」は、AWS のサービスの障害や予定の保守を知らせる画面です。「Amazon CloudWatch」は、資源の数値やログを集めて見張るサービスです。出典 https://docs.aws.amazon.com/artifact/latest/ug/what-⁠is-⁠aws-⁠artifact.html

正解は「ブラウザと Web サーバーの間を TLS でつなぐ」です。Amazon S3 の暗号化の文書は、データの保護を、行き来している途中のデータ (転送中) と、データセンターのディスクに保存されたデータ (保管時) に分けて説明しています。そして転送中のデータは SSL/TLS で守れると書いています。HTTPS で始まる Web サイトの通信は、この TLS を使っています。「保存先のディスクで暗号化しておく」は、文書でいうサーバー側の暗号化で、保管時の暗号化です。「ディスクを作るときに暗号化を有効にする」も、置いたデータを守るので保管時です。「バックアップを暗号化して残す」も、保存した物を守る保管時の暗号化に当たります。出典 https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingEncryption.html

正解は「Amazon GuardDuty」です。Amazon GuardDuty の文書は、AWS の環境のデータとログを常に見張って分析する脅威の検出のサービスだと説明しています。悪意のある IP アドレスやドメインの一覧、機械学習のモデルを使い、怪しい動きを見つけます。有効にすると、AWS CloudTrail の操作の記録、VPC フローログ、DNS のログを自動で読み始めます。「Amazon Inspector」は、ソフトの既知の弱点を調べるサービスで、操作の怪しさは見ません。「AWS Config」は、資源の設定とその移り変わりを記録するサービスです。「AWS Shield Standard」は、DDoS 攻撃を自動で防ぐ守りで、ログから怪しい操作を見つける物ではありません。出典 https://docs.aws.amazon.com/guardduty/latest/ug/what-⁠is-⁠guardduty.html

正解は「Amazon Inspector」です。Amazon Inspector の文書は、作業の対象を自動で見つけ、ソフトの脆弱性と意図しないネットワークの露出を調べ続ける脆弱性の管理のサービスだと説明しています。対象には EC2 のインスタンスや Amazon ECR のコンテナのイメージが含まれ、手で調べる日程を組む必要はありません。見つかると、影響する資源と直し方を示す結果 (finding) を出します。「Amazon GuardDuty」は、ログから怪しい動きを見つける脅威の検出のサービスです。「AWS Artifact」は、AWS の監査の報告書を取り寄せる場所です。「AWS WAF」は、Web アプリへの悪い要求を止める仕組みで、入っているソフトの弱点は調べません。出典 https://docs.aws.amazon.com/inspector/latest/user/what-⁠is-⁠inspector.html

正解は「AWS Config」です。AWS Config の文書は、アカウントの中の AWS の資源の設定を詳しく見せ、過去にどう設定されていたかと、その変化を追えるサービスだと説明しています。例として、EC2 のセキュリティグループで、ある時点にどのポートのルールが開いていたかを見られると書いています。さらに、ルールで設定を評価し、決まりに合わない資源に印を付けることもできます。「Amazon CloudWatch」は、性能の数値やログを見張るサービスで、設定の履歴を残す物ではありません。「AWS Trusted Advisor」は、いまの設定に対する改善の勧めを出すサービスです。「Amazon Inspector」は、ソフトの脆弱性を調べるサービスです。出典 https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html

正解は「AWS Security Hub」です。AWS Security Hub の文書 (いまの文書では Security Hub CSPM と呼ばれる機能) は、AWS でのセキュリティの状態を全体で見せ、業界の基準やベストプラクティスに照らして環境を評価するサービスだと説明しています。複数のアカウント、AWS のサービス、対応する他社の製品からセキュリティのデータを集め、最も優先すべき問題を見つける助けになります。「Amazon GuardDuty」は脅威を見つける側のサービスで、基準に照らした点検や結果の集約は行いません。「AWS Shield Advanced」は DDoS 攻撃への強い守りです。「AWS Artifact」は AWS 自身の監査の報告書を配る場所で、利用者の環境は点検しません。出典 https://docs.aws.amazon.com/securityhub/latest/userguide/what-⁠is-⁠securityhub.html

正解は「Amazon Detective」です。Amazon Detective の文書は、セキュリティの検出結果や怪しい動きを分析して調べ、その根本の原因を素早く見つける助けになるサービスだと説明しています。AWS の資源からログを自動で集め、機械学習や統計、グラフの理論を使って、操作の変化を図で見せます。最大 1 年分の過去のデータを見られ、変化を GuardDuty の検出結果と結び付けてくれます。「Amazon Inspector」は、ソフトの脆弱性を調べるサービスで、起きた出来事の原因はさかのぼりません。「AWS Artifact」は、AWS の監査の報告書を取り寄せる場所です。「AWS Firewall Manager」は、ファイアウォールのルールを複数のアカウントへ配るサービスで、調査には使いません。出典 https://docs.aws.amazon.com/detective/latest/adminguide/what-⁠is-⁠detective.html

正解は「AWS Firewall Manager」です。AWS Firewall Manager の文書は、AWS WAF、AWS Shield Advanced、VPC のセキュリティグループやネットワーク ACL などの守りを、複数のアカウントと資源にまたがって管理する手間を減らすサービスだと説明しています。守りを一度決めれば、新しく加わったアカウントや資源にも自動で当ててくれます。「AWS Config」は設定を記録して評価するサービスで、ファイアウォールのルールを配る物ではありません。「AWS Shield Standard」は全員に自動で効く DDoS の守りで、利用者がルールを決めて配る仕組みではありません。「Amazon Inspector」は脆弱性を調べるサービスです。出典 https://docs.aws.amazon.com/waf/latest/developerguide/fms-⁠chapter.html

正解は「AWS Marketplace」です。AWS Marketplace の文書は、AWS 以外の会社 (サードパーティー) のソフトウェア、データ、サービスを探し、買い、配置し、管理できるカタログだと説明しています。分野にはセキュリティやネットワークが含まれ、設定済みのソフトを数回の操作で起動できます。「AWS Artifact」は、AWS の監査の報告書や契約の文書を取り寄せる場所で、製品は売っていません。「AWS Security Hub」は、セキュリティの状態を点検して結果を集めるサービスで、製品を買う場所ではありません。「AWS Knowledge Center」は、よくある質問と答えを読める情報の置き場です。出典 https://docs.aws.amazon.com/marketplace/latest/buyerguide/what-⁠is-⁠marketplace.html

正解は「対象のサービスの一覧で、使うサービスを確かめる」です。AWS は「AWS Services in Scope by Compliance Program」という頁で、どのサービスがどの認証や監査の対象に入っているかを一覧にしています。頁は、対象に入るサービスは使い方の見込みや要望で決まると説明し、一覧に無いサービスについては、扱うデータの性質を見て利用者が判断する責任があると書いています。つまり、基準への対応はサービスごとに違います。「どのサービスも対象と考える」は、一覧がある理由と合いません。「国内のリージョンを選べば」と「IAM で権限を絞れば」は、どちらもサービスが監査の対象かどうかを変えません。出典 https://aws.amazon.com/compliance/services-⁠in-⁠scope/

正解は「MFA (多要素認証) を設定し、日々の作業には使わない」です。IAM の文書のルートユーザーのベストプラクティスは、ルートユーザーのサインインを MFA で守ること、日々の作業には管理用のユーザーを別に作ることを勧めています。MFA はパスワードに加えて手元の機器の確認を求めるので、パスワードが漏れても入られにくくなります。「アクセスキーを作り、共有して使う」は誤りで、文書はルートユーザーのアクセスキーを作らないこと、認証情報をだれとも共有しないことを求めています。「パスワードを短くする」は、強いパスワードを使うという勧めと逆です。「日々の作業もルートユーザーで行う」も、使う場面を限るという勧めに反します。出典 https://docs.aws.amazon.com/IAM/latest/UserGuide/root-⁠user-⁠best-⁠practices.html

正解は「AWS アカウントそのものを閉じる」です。IAM の文書の「ルートユーザーの認証情報が必要な作業」の一覧は、AWS Organizations に入っていない単独のアカウントでは、アカウントを閉じるのにルートユーザーの認証情報が要ると書いています。同じ一覧には、メールアドレスやルートユーザーのパスワードの変更なども並んでいます。「IAM ユーザーを作って権限を付ける」は、管理の権限を持つ IAM のユーザーやロールで行えます。「EC2 のインスタンスを起動して止める」と「S3 にバケットを作ってファイルを置く」も、IAM のポリシーで許可を受けたユーザーやロールが行える日々の作業で、ルートユーザーは要りません。出典 https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-⁠user.html

正解は「請求の情報を見る権限だけを付ける」です。IAM のセキュリティのベストプラクティスは、IAM のポリシーで権限を付けるとき、作業に必要な権限だけを付けるよう求めています。どの資源に、どの操作を許すかを仕事に合わせて絞ることを、最小権限の考え方と呼びます。権限を絞っておけば、認証情報が漏れたり操作を誤ったりしても、被害の範囲が小さくなります。「すべてのサービスの情報を読める権限」は、読むだけでも請求と関係のない資源の中身まで見えてしまい、仕事に必要な範囲を超えます。「見る権限と変える権限を両方付ける」は、この担当者に要らない変更の権限が残ります。「管理者の権限を付けて見張る」は、操作の記録はあとで調べる助けにはなりますが、そもそも必要以上の権限を渡しているので原則に反します。出典 https://docs.aws.amazon.com/IAM/latest/UserGuide/best-⁠practices.html

正解は「複数の IAM ユーザーに同じ権限をまとめて付ける入れ物」です。IAM の文書は、IAM のユーザーグループを IAM ユーザーの集まりと説明し、複数のユーザーの権限をまとめて決められるので管理が楽になると書いています。グループにポリシーを付けると、中のユーザー全員がその権限を受け取ります。「グループの名前でサインインできる」は誤りで、グループは権限のための物で、認証 (本人の確かめ) には使いません。サインインするのは中の IAM ユーザーです。「バケットポリシーで名指しできる」も誤りで、文書は、グループを資源の側のポリシーで許す相手 (Principal) に指定できないと書いています。「一時的に権限を借りる仕組み」は IAM ロールの説明です。出典 https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html

正解は「AWS 管理ポリシー」です。IAM の文書は、ID に付けるポリシーの種類を比べ、AWS 管理ポリシーを AWS が作って管理する独立したポリシーだと説明しています。管理するのは AWS で、利用者は中身を書き換えられず、多くのユーザーやロールに付けて使い回せます。手早く始めるには便利ですが、文書は、そこから最小権限へ絞っていくよう勧めています。「カスタマー管理ポリシー」は、利用者が自分の用途に合わせて作り、何度でも直せるポリシーです。「インラインポリシー」は、1 つのユーザーやロールに直接埋め込む、使い回さないポリシーです。「サービスコントロールポリシー」は、AWS Organizations でアカウントに許す操作の上限を決める物です。出典 https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-⁠vs-⁠inline.html

正解は「AWS Secrets Manager」です。AWS Secrets Manager の文書は、データベースの認証情報、API キーなどの秘密の情報を、管理し、取り出し、取り替えるサービスだと説明しています。ソースコードに書いたパスワードを、実行のときに Secrets Manager から取り出す呼び出しに置き換えれば、コードを見た人に漏れません。自動の取り替えの周期も設定できます。「AWS KMS」は暗号化の鍵を作って管理するサービスで、パスワードを預かって自動で取り替える仕組みではありません。「AWS Config」は資源の設定を記録するサービスです。「AWS CloudTrail」は操作の記録を残すサービスで、秘密の情報の置き場ではありません。出典 https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html

正解は「IAM の認証情報レポートを作って取り出す」です。IAM の文書は、認証情報レポート (credential report) を作ってダウンロードすると、アカウントのすべてのユーザーと、パスワード、アクセスキー、MFA の機器などの認証情報の状態が一覧で得られると説明しています。パスワードを最後に使った日、アクセスキーを最後に替えた日、MFA が有効かも欄にあり、監査やコンプライアンスに使えるとしています。「パスワードポリシーの設定」は、パスワードの条件の決まりを示すだけで、ユーザーごとの状態は出ません。「AWS Artifact の監査の報告書」は、AWS 自身の基盤についての物です。「CloudTrail のイベント履歴」は操作の記録で、MFA の有無の一覧にはなりません。出典 https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-⁠report.html

正解は「IAM ロールを EC2 に付け、一時的な認証情報を使う」です。IAM の文書は、EC2 で動くアプリには、長く使える認証情報を置く代わりに IAM ロールで一時的な認証情報を渡すべきだと説明しています。ロールを使えば、サインインの情報やアクセスキーをインスタンスに配る必要がありません。一時的な認証情報は自動で更新されるので、管理の手間と長く残る危険を減らせます。「IAM ユーザーのアクセスキーを設定ファイルに書く」は、文書が避けるべきとする長期の認証情報を置く方法です。「ルートユーザーのアクセスキーを渡す」は、すべての権限が漏れる危険があります。「だれでも読める設定にする」は、外の人にもデータを見せてしまいます。出典 https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-⁠role-⁠ec2.html

正解は「アカウントの IAM のパスワードポリシーを設定する」です。IAM の文書は、AWS アカウントに独自のパスワードポリシーを設定すると、IAM ユーザーのパスワードに複雑さの条件と、決まった期間での変更を求められると説明しています。最低の長さ、大文字や数字などの文字の種類、有効期限を決められます。なお、このポリシーはルートユーザーのパスワードやアクセスキーには効きません。「AWS Shield」は DDoS 攻撃を防ぐ守りで、パスワードの条件は決めません。「AWS Config のルール」は設定を評価する物で、パスワードを変える仕組みではありません。「AWS 管理ポリシー」は操作の権限を決める物で、パスワードの決まりとは別です。出典 https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-⁠policy.html

正解は「ID フェデレーション」です。ID フェデレーションは ID の連携という意味です。IAM の文書は、人が AWS を使うときは、アカウントに IAM ユーザーを一人ずつ作るのではなく、ID プロバイダー (IdP) とのフェデレーションで入ることをベストプラクティスとして勧めています。ID は AWS の外で管理し、その外の ID に AWS の資源を使う権限を与えます。社員は社内の仕組みでサインインし、AWS 側で長く使うパスワードを持たずに済みます。「最小権限の原則」は、付ける権限を必要な分に絞る考え方で、ID をどこで管理するかとは別の話です。「クロスアカウントアクセス」は、別の AWS アカウントの資源を使わせる仕組みです。「多要素認証」は MFA とも呼ばれ、、サインインの確かめを強める方法です。出典 https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html