- ジョギング
- 日課
- 引越し準備追い込み
- 香椎最後の夜
- 今日の AWS ~ AWS Certified Solutions Architect – Professional Level のサンプル問題に挑む ~
ジョギング
- おやすみ
- なぜか全身筋肉痛
日課
- おやすみ
引越し準備追い込み
- 奥さんにほとんど任せっきりだったので, 今日ぐらいはちゃんと手伝えればと思ったけど...あんまり役に立たなかったみたい
- ひとまず, 明日はなんとかなるさ〜
香椎最後の夜
- しっぽりと更けていく感じ
- 明日も早いのでさっさと寝よう
今日の AWS ~ AWS Certified Solutions Architect – Professional Level のサンプル問題に挑む ~
公開されているサンプル試験問題を解く. なぜ, その答えになるのかをちゃんと理解する必要がある.
Q4. 機密性の高い情報の保護するアーキテクチャ (AWS CloudHSM)
設問
- 機密性の高い情報を取得してユーザーに表示するWebサイトを構築している
- サイトへのトラフィック量は想定されていない
- サイトは SSL を利用してクライアントと Web サーバー間の通信を保護する
- SSL 秘密鍵について, 誤ってか意図せずに自分の環境の外に鍵を移動できないようにする必要がある
- サイトに表示されるデータは暗号化された EBS ボリュームに保存される
- Web サーバーのログには機密情報が含まれている可能性がある為, ログは社員のみが解読できるように保存する必要がある
これらすべての要件を満たすアーキテクチャはどれか.
選択肢
A) Use Elastic Load Balancing to distribute traffic to a set of web servers. To protect the SSL private key, upload the key to the load balancer and configure the load balancer to offload the SSL traffic. Write your web server logs to an ephemeral volume that has been encrypted using a randomly generated AES key.
- Elastic Load Balancing を使って, 一連の Web サーバーにトラフィックを分散させる
- SSL 秘密鍵を保護は, 鍵をロードバランサにアップロードしてロードバランサを設定して SSL トラフィックをオフロードする
- ランダムに生成された AES キーを使用して暗号化されたエフェメラルボリュームに Web サーバーログを書き込む
B) Use Elastic Load Balancing to distribute traffic to a set of web servers. Use TCP load balancing on the load balancer and configure your web servers to retrieve the private key from a private Amazon S3 bucket on boot. Write your web server logs to a private Amazon S3 bucket using Amazon S3 server-side encryption.
- Elastic Load Balancingを使って, 一連の Web サーバーにトラフィックを分散させる
- ロードバランサで TCP ロードバランシングを使用して, 起動時に非公開の Amazon S3 バケットから秘密鍵を取得するようにWebサーバーを構成する
- Amazon S3 サーバー側の暗号化を使用して, Web サーバーログを非公開の Amazon S3 バケットに書き込む
C) Use Elastic Load Balancing to distribute traffic to a set of web servers, configure the load balancer to perform TCP load balancing, use an AWS CloudHSM to perform the SSL transactions, and write your web server logs to a private Amazon S3 bucket using Amazon S3 server-side encryption.
- Elastic Load Balancing を使用して, Web サーバーのセットにトラフィックを分散して TCP ロードバランシングを構成する
- また, ELB にて AWS CloudHSM を使用して SSL トランザクションを実行する
- プライベートな Amazon S3 バケットに S3 サーバー側の暗号化を用いて Web サーバーログを書き込む
D) Use Elastic Load Balancing to distribute traffic to a set of web servers. Configure the load balancer to perform TCP load balancing, use an AWS CloudHSM to perform the SSL transactions, and write your web server logs to an ephemeral volume that has been encrypted using a randomly generated AES key.
- Elastic Load Balancing を使用して, 一連のWebサーバーにトラフィックを分散する
- TCP ロードバランシングを実行するようにロードバランサを設定し, AWS CloudHSM を使用してSSLトランザクションを実行する
- ランダムに生成された AES キーを使用して暗号化されたエフェメラルボリュームに Web サーバーログを書き込む
解答
- C かな...
なぜ, その答えなん？
いつもの消去法.
- A) ELB で SSL をオフロードさせるのは良さそう, ただ, ログデータをエフェメラルストレージに書き込むのはいかがなものか
- B) S3 バケットから秘密鍵を取得するようにって... うっかりバケットから鍵を削除してしまうこともありうるので要件を満たされていない
- D) については, CloudHSM で秘密鍵の管理は安心できそうだけど, A) と同様にログをエフェメラルストレージに置いて大丈夫なん？
ということで, 消去法でいくと C) になるかなと.
え, AWS CloudHSM って何？
- AWS CloudHSM （法令遵守のためのキーストレージ ） | AWS
- AWS CloudHSM とは - AWS CloudHSM
- AWS CloudHSM のユースケース - AWS CloudHSM
Q5. ネットワーク設計
設問
- ファットクライアントアプリケーション用のネットワーク接続を設計している
- ホテルの客室, カフェ, 公共 Wi-Fi ホットスポット, およびインターネットの他の場所から接続できる必要があるビジネストラベラー向けに設計されている
- インターネット上にアプリケーションを公開する必要は無い
- 展開と運用コストを最小限に抑えながら, どのネットワーク設計が上記の要件を満たしているか
選択肢
A) Implement AWS Direct Connect, and create a private interface to your VPC. Create a public subnet and place your application servers in it.
- AWS Direct Connect を実装して VPC へのプライベートインターフェイスを作成する
- パブリックサブネットを作成し, アプリケーションサーバーを配置する
B) Implement Elastic Load Balancing with an SSL listener that terminates the back-end connection to the application.
- アプリケーションへのバックエンド接続を終端する SSL リスナーを使用して Elastic Load Balancing を実装する
C) Configure an IPsec VPN connection, and provide the users with the configuration details. Create a public subnet in your VPC, and place your application servers in it.
- IPsec VPN 接続を構成し, ユーザーに構成の詳細を提供する
- VPC にパブリックサブネットを作成してアプリケーションサーバーを配置する
D) Configure an SSL VPN solution in a public subnet of your VPC, then install and configure SSL VPN client software on all user computers. Create a private subnet in your VPC and place your application servers in it.
- VPC のパブリックサブネットに SSL VPN ソリューションを設定し, 全ユーザコンピュータに SSL VPN クライアントソフトウェアをインストールして設定する
- VPC にプライベートサブネットを作成し, アプリケーションサーバーをそのサブネットに配置する
解答
- うーむ, アプリケーションはインターネット上に公開する必要がないという要件だけを考慮すると D なのかなあ
- ただ, 運用コストを考慮すると, 全ユーザーコンピュータに SSL VPN クライアントをインストールって辛い
なぜ, その答えなん？
- A) は Direct Connect の運用コストが高いし, アプリケーションサーバーはパブリックサブネットに配置する必要は無い
- B) インターネットに公開しないので ELB は要らないと思う (SG で蓋をしてしまえばいいけど, そこまで言及されていない)
- C) アプリケーションサーバーはパブリックサブネットに展開する必要がない, VPN の構成情報をアプリユーザーに提供する点に違和感 (セキュアじゃない？)
ということで, これまた消去法.
