SOA-#041

SOA#40 — SOA#41 — SOA#42
R – F

お疲れ様でした!SOA#41のクイズ終了しました。

解答スコアは %%SCORE%% / %%TOTAL%% 問正解です。

%%RATING%%


あなたの選択した答えは強調表示されています。
問題1
複数のコンポーネントで作成されたアプリケーションがあり、VPC 内の単一の EC2 インスタンスで ELB なしでホストされています。この場合、各コンポーネントに 2 つの別々の SSL を設定する必要があり、単一の EC2 インスタンスを使用しながら、2 つの別々の SSL を設定できる方法を選択してください。
A
複数のサブネットが接続された EC2 インスタンスを作成してそれぞれに個別の IP アドレスを割り当てます。
B
EC2 インスタンスに複数の Elastic IP アドレスを持つ複数のネットワークインターフェイスを割り当てます。
C
ACL とセキュリティグループの両方がアタッチされている EC2 インスタンスを作成し、それぞれの IP アドレスに対して別々のルールを割り当てます。
D
NAT アドレスを使用して EC2 インスタンスを作成します。
問題 1 の説明および補足 
複数の IP アドレス
EC2 インスタンスに複数の Elastic Network Interface(ネットワークインターフェース または ENI)を接続することができ、それぞれのネットワーク IP は別々の SSL 証明書を使用してコンポーネントを実行させることができます。

※複数の IP アドレス インスタンスに複数のプライベート IPv4 および IPv6 アドレスを指定できます。インスタンスに指定できるネットワークインターフェイスとプライベート IPv4 および IPv6 アドレスの数は、インスタンスタイプによって異なります。

次のような場合、複数の IP アドレスを VPC 内のインスタンスに割り当てると便利です。

・1 つのサーバーで複数の SSL 証明書を使用し、各インターフェイスに各 IP アドレスに割り当てることで、1 つのサーバーで複数のウェブサイトをホストする。

・各ネットワークインターフェイス用に複数の IP アドレスを持つネットワークアプライアンス (ファイアウォールやロードバランサーなど) を運用する。

・インスタンスでエラーが発生した場合に、セカンダリ IP アドレスをスタンバイインスタンスに再割り当てすることによって、内部トラフィックをスタンバイインスタンスにリダイレクトする。
参考URL:複数の IP アドレス
問題2
システム管理者は、AWS マネジメントコンソールや AWS CLI へのアクセスをより合理化し、安全性を高めることを検討しています。社内の IT リソースとして Active Directory を利用していますが、AWS の場合はアカウントの所有者(root)ログインをユーザーが共有しています。管理者がアクセスをより安全かつ合理化するために推奨される方法を選択してください。
A
可逆的な暗号化を使用してActive Directoryのログイン情報を保存します。管理者の Active Directory ログイン情報を照会し、一致する AWS ログインとパスワードを同期させるスクリプトを実装します。
B
コンソールに対して、ルートユーザでのログインを中止し、SSH キーを用いたログインに変更します。SSH キーが 90 日ごとにローテーションされていることを確認し、コンソールに対するパスワード認証を無効にします。
C
AWS アクセスを必要とするユーザーごとに IAM ユーザーを作成し、IAM グループを使用して Active Directory のグループをミラーリングします。必要に応じて、ユーザーのパスワードを同期させます。
D
AWS と会社の Active Directory の間に SAML フェデレーションを設定します。Active Directory のグループを IAM グループにマッピングし、ユーザーの権限を管理します。
問題 2 の説明および補足 
IAM SAML ID プロバイダーの作成
SAMLフェデレーションを Active Directory と AWS の間に ID プロバイダーを使用してアクセス許可を管理し、各ユーザーに一時的な認証情報を付与することができます。
参考URL:IAM SAML ID プロバイダーの作成

※SAML 2.0 ベースのフェデレーションについて
SAMLフェデレーションは Active Directory と AWS 間の ID ブローカーとして使用できます。
AWS は SAML 2.0 (Security Assertion Markup Language) を使用した ID フェデレーションをサポートします。これは、多くの ID プロバイダー (IdP) により使用されているオープンスタンダードです。この機能はフェデレーティッドシングルサインオン (SSO) を有効にします。したがって、組織内の全員について IAM ユーザーを作成しなくても、ユーザーは AWS マネジメントコンソール にログインしたり、AWS API オペレーションを呼び出したりできるようになります。SAML を利用すると、カスタム ID プロキシコードを記述する代わりに IdP のサービスを利用できるため、AWS で簡単にフェデレーションを設定できます。
参考URL:SAML 2.0 ベースのフェデレーションについて
問題3
あなたの会社のアプリケーションは、Classic Load Balancer の背後で動作する Auto Scaling の EC2 インスタンスと RDS インスタンスで構成されています。クライアントで、ロードバランサーへの接続時にエラー「HTTP: 503 Service Unavailable」または「HTTP: 504 Gateway Timeout」が発生することがあります。また、CloudWatch メトリクスから、 " SpilloverCount " の値が高いことを確認しました。" SpilloverCount " の値が上昇しないようにするために監視する有効なメトリクスを選択してください。
A
BackendConnectionErrors
B
SurgeQueueLength
C
CPU 使用率
D
HealthyHostCount
問題 3 の説明および補足 
Classic Load Balancer メトリクス
SurgeQueueLength は正常なインスタンスへのルーティングを保留中のリクエスト (HTTP リスナー) または接続 (TCP リスナー) の合計数です。キューがいっぱいになると拒否されて、SpilloverCount がカウントされます。したがって、SurgeQueueLength を監視することで目的を達成できます。

※Classic Load Balancer メトリクス
・SurgeQueueLength
正常なインスタンスへのルーティングを保留中のリクエスト (HTTP リスナー) または接続 (TCP リスナー) の合計数。キューの最大サイズは 1,024 です。追加のリクエストまたは接続は、キューがいっぱいになると拒否されます。詳細については、「SpilloverCount」を参照してください。

・SpilloverCount
サージキューがいっぱいなため、拒否されたリクエストの総数。
[HTTP リスナー] ロードバランサーは、HTTP 503 エラーコードを返します。
参考URL:Classic Load Balancer メトリクス
問題4
あなたはソリューションアーキテクトとして、Amazon の仮想プライベートクラウド(VPC)への電子商取引プラットフォームの移行をサポートしています。移行前のアーキテクトはすでに 3 層の VPC を導入しています。

設定は次の通りです。
VPC: vpc-2f8bc447
IGW: igw-2d8bc445
NACL: ad-208bc448

・Subnets and Route Tables:
Web server’s subnet-258Dc44d
Application server’s suDnet-248bc44c
Database server’s subnet-9189c6f9

・Route Tables:
rtb-218bc449
rtb-238bc44b

・Associations:
subnet-258Dc44d : rtb-218bc449
subnet-248bc44c : rtb-238bc44b
subnet-9189c6f9 : rtb-238bc44b

EC2 インスタンスを VPC に展開する準備が整いました。ウェブサーバーはインターネットに直接アクセスできます。アプリケーションサーバーとデータベースサーバーはインターネットに直接アクセスできません。以下のどの設定を使用すると、アプリケーションサーバーとデータベースサーバーをリモートで管理して、これらのサーバーがインターネットから更新プログラムを取得できるようになりますか。
A
rtb-238bc44b から igw-2d8bc445 へのルートを追加し、Subnet-248DC44c 内に Bastion と NAT インスタンスを追加します。
B
subnet-258Dc44d に Bastion および NAT インスタンスを作成し、rtb-238bc44b から igw-2d8bc445 にルートを追加します。
C
subnet-258Dc44d に Bastion および NAT インスタンスを作成し、rtb-238bc44b から subnet-258Dc44d にルートを追加します。
D
subnet-258Dc44d に Bastion および NAT インスタンスを作成し、rtb-238bc44b から NAT インスタンスにルートを追加します。
問題 4 の説明および補足 
NAT 経由でのアクセス
アクセスルールを理解する必要がある問題になります。
アプリケーションサーバーとデータベースサーバーをリモート管理したり、これらのサーバーがインターネットから更新プログラムを取得する必要がある、と記載があります。直接インターネットへ公開するのはセキュティー上好ましくないため、NAT 経由でアクセスできる構成を考慮していきます。
現在、ウェブサーバーはインターネットに直接アクセスできるため、ウェブサーバーの subnet-258Dc44d に Bastion および NAT インスタンスを作成します。次に、アプリケーションサーバーとデータベースサーバのルート(rtb-238bc44b)を NAT インスタンスのルートに追加します。
問題5
Amazon EC2 フリート上のゲスト OS に対して、セキュリティ監査を実施したところ、既知の脆弱性が発見されました。 システム管理者は、この脆弱性を直ちに緩和する必要があります。このタスクを実行するための最も効率的な方法を選択してください。
A
AWS Systems Manager を使用して EC2 フリートの全フリートに対してセキュリティパッチを適用します。
B
EC2 インスタンスの停止と開始を行い、強制的にセキュリティパッチを適用します。
C
インスタンス全体にセキュリティパッチが適用されるように、AWS サポートにリクエストします。
D
毎週のメンテナンスウィンドウで AWS にセキュリティパッチを自動的に適用します。
問題 5 の説明および補足 
AWS Systems Manager Patch Manager
AWS Systems Manager Patch Manager は、セキュリティ関連の更新パッチをマネージドインスタンスに適用するプロセスを自動化します。Linux ベースのインスタンスの場合は、セキュリティに関連しない更新プログラムのパッチもインストールできます。オペレーティングシステムのタイプ別に、Amazon EC2 インスタンスまたはオンプレミスサーバー、および仮想マシン (VM) にパッチを適用できます。Windows Server、Ubuntu Server、Red Hat Enterprise Linux (RHEL)、SUSE Linux Enterprise Server (SLES)、CentOS、Amazon Linux、Amazon Linux 2 のサポートされているバージョンが対象になります。インスタンスをスキャンし、見つからないパッチのレポートのみを表示できます。または、すべての見つからないパッチをスキャンして自動的にインストールできます。
参考URL:AWS Systems Manager Patch Manager

※Amazon EC2 フリート
Amazon EC2 フリートは、さまざまな Amazon EC2 インスタンスタイプ、アベイラビリティーゾーン、オンデマンド、Amazon EC2 リザーブドインスタンス (RI)、Amazon EC2 スポット購入モデルの間での Amazon EC2 キャパシティーのプロビジョニングを簡素化する新機能です。単一の API コールで、EC2 インスタンスタイプや購入モデルの間でキャパシティーをプロビジョンして、必要な規模、パフォーマンス、コストを達成できます。

■以下は間違いです。
・インスタンス全体にセキュリティパッチが適用されるように、AWS サポートにリクエストします。
→システム管理者の責任において EC2 インスタンスにパッチを適用するので効率的ではありません。

・毎週のメンテナンスウィンドウで AWS にセキュリティパッチを自動的に適用します。
→ AWS は EC2 インスタンスに自動的にパッチを適用しないため間違いです。

・EC2 インスタンスの停止と開始を行い、強制的にセキュリティパッチを適用します。
→EC2 インスタンスを再起動したのみでは、強制的にセキュリティパッチを適用できないため間違いです。
問題6
あなたの会社は、重要な収益を生み出すアプリケーションをホストしています。近年、このアプリケーションは大規模な DDoS 攻撃を受けています。その結果、多くのユーザーがアプリケーションの動作の遅さに不満を感じてます。今後、このような状況を回避する必要があり、将来同様な状況が発生した場合には、AWS から 24 時間 365 日のサポートを受ける必要があります。この点で役立つサービスを選択してください。
A
AWS Shield アドバンスド
B
AWS Systems Manager
C
Amazon Inspector
D
AWS WAF
問題 6 の説明および補足 
AWS Shield アドバンスド
AWS Shield アドバンスドが 24 時間 365 日の DDoS 対応で DDoS 保護を提供し、スパイクに対する支援とコスト面での保護を提供します。

※AWS Shield アドバンスド
Amazon Elastic Compute Cloud、Elastic Load Balancing (ELB)、Amazon CloudFront、Amazon Route 53、AWS Global Accelerator などのリソースで実行されるウェブアプリケーションを標的とした攻撃に対する高レベルな保護には、AWS Shield アドバンスド をサブスクライブできます。AWS Shield アドバンスド は、DDoS 攻撃に対するこのようなリソースの拡張保護を提供します。
この追加された保護の例として、Shield アドバンスド を使用して Elastic IP アドレスを保護する場合、攻撃中に Shield アドバンスド は AWS ネットワークの境界にネットワーク ACL を自動的にデプロイします。これにより、Shield アドバンスド はより大きな DDoS イベントに対して保護を提供します。通常、ネットワーク ACL は Amazon VPC 内の Amazon EC2 インスタンスの近くで適用されます。ネットワーク ACL は、Amazon VPC とインスタンスが処理できるだけの大きさの攻撃を緩和できます。たとえば、Amazon EC2 インスタンスに接続されたネットワークインターフェイスが最大 10 Gbps を処理できる場合、10 Gbps を超えるボリュームは遅くなり、そのインスタンスへのトラフィックをブロックする可能性があります。攻撃中に、Shield アドバンスド はネットワーク ACL を AWS 境界に昇格させ、数テラバイトのトラフィックを処理できます。ネットワーク ACL は、典型的なネットワークの容量を超えてリソースを十分に保護することができます。
AWS Shield アドバンスド のお客様は、DDoS 攻撃を受けている中、24 時間 365 日体制の DDoS response team (DRT) にサポートを依頼できます。また、高度なリアルタイムのメトリクスとレポートへの排他的アクセスが可能であり、AWS リソースに対する攻撃の広範な可視性を得られます。DRT のサポートにより、AWS Shield アドバンスド には、ネットワークレイヤー (レイヤー 3) およびトランスポートレイヤー (レイヤー 4) 攻撃だけでなく、アプリケーションレイヤー (レイヤー 7) 攻撃に対しても、DDoS 攻撃のインテリジェント検出および軽減が含まれます。
参考URL:AWS Shield アドバンスド

■以下は間違いです。
・Amazon Inspector
→Amazon Inspector は自動化されたセキュリティを評価して、AWS にデプロイしたアプリケーションのセキュリティとコンプライアンスを向上させるサービスのため間違いです。

・AWS WAF
→AWS WAF は ファイアウォールであり、24 時間 365 日のサポートは提供しないため間違いです。

・AWS Systems Manager
→AWS Systems Manager は、AWS でご利用のインフラストラクチャを可視化し、制御するためのサービスのため間違いです。
問題7
あなたの会社は、機密データの保存に S3 を使用しています。 CIO は、バケット内のデータへの不正アクセスを心配しています。既存のユーザーに対してバケットの必要以上のアクセス制限をかけずに、セキュリティ対策を実施できる方法を選択してください。
A
IAM ポリシーを使用し、PutObject の Action に対して DENY ステートメントを設定します。
B
AWS Config を使用して、パブリックアクセスの S3 バケットが作成された場合、監視と通知を行います。
C
バケットのバージョニングを有効にします。
D
バケットポリシーを使用して、PutObject の Action に対して DENY ステートメントを設定します。
問題 7 の説明および補足 
AWS Config
AWS Config では、パブリックアクセスのある S3 バケットが作成された場合に監視とアラートを行うころができます。

※インターネットからアクセス可能な S3 バケットを調べる方法
S3 バケットへのパブリックアクセスが可能かどうかは、Amazon S3 コンソールのバケットのアクセス許可チェックを使うか、AWS Trusted Advisor の Amazon S3 バケットアクセス許可チェックを使って調べることができます。AWS アカウントに多くの S3 バケットがある場合は、AWS Config を使用して、どのバケットが読み取りまたは書き込みのパブリックアクセスを許可されているのかを迅速に特定することができます。さらに、最初に確認した後で S3 バケットのパブリックアクセスが可能となった場合、それを通知するように AWS Config を設定することもできます。

◇動画:Ioannis が、AWS Config を使用して S3 バケットを保護する方法について説明します。

参考URL:インターネットからアクセス可能な S3 バケットを調べる方法を教えてください。

■以下は間違いです。
・バケットのバージョニングを有効にします。
→バージョニングが有効なバケットでは、オブジェクトを誤って削除または上書きしても復元するため用途が異なります。

・バケットポリシーを使用して、PutObject の Action に対して DENY ステートメントを設定します。
・IAM ポリシーを使用し、PutObject の Action に対して DENY ステートメントを設定します。
→内部ユーザに対しても制限がかかるため間違いです。
お疲れさまでした。 クイズが完了したら、「クイズの結果を見る」ボタンをクリックしてください。あなたが完了していないアイテムは、間違いのマークがされます。 クイズの結果を見る
問題は全部で 7 問。全て答えられるように頑張りましょう!
リスト
戻る
網掛け部分は完了した項目です。
12345
67ゴール
戻る