こんにちは、kouです。
AWS認定テキスト クラウドプラクティショナーの第3章のまとめを紹介します。
使用した書籍の紹介
最初に
アマゾンさんは、このAWSの中で、セキュリティに関して最重要項目だと位置付けているようです。
以前、無料オンラインセミナーを受講しました。
そのときに、スピーカーだったアマゾン社員の方が、そう言っていたので間違いないでしょう(笑)
また、クラウドプラクティショナーは、その他の章でも同様に、深い内容は問われないみたいです。
ある程度知っているかどうかが重要です。
本の内容をアウトプットしていきます。
それでは、早速説明していきます。
AWSの責任共有モデル
AWSでは、明確にセキュリティに関して、責任範囲を明確にしています。
以下に説明していきますが、「でしょうね～」という内容だと思います。
試験問題としては、ユーザが考えないといけない部分か、
AWSにお任せでいいのかの役割のすみ分けを理解しているかどうかが出題されます。
責任範囲の考え方のざっくり結論としては、以下です。
- ユーザが作りこむことができるところは、ユーザの責任だよ。
- ユーザが触れないところ・気にしなくてよいところは、AWSの責任だよ。
少し詳しく書きます。
AWSは、実にたくさんのサービス、機能を提供してくれています。
ここで、AWSの公式サイトから図をお借りします。
一目でわかると思います。
当然、ユーザ側で採用し、構成するサービスの組み合わせによって、責任は異なります。
ただ、基本的にAWSが提供しているサービスや機能を実現し動かしているインフラ部分は、
AWSがすべて責任を負います。
実際、ユーザ側でやろうとしても、操作したり扱えないのでムリですよね・・・
ですので、ユーザ側の責任を具体的に言うと、
- ゲストオペレーティングシステム (更新とセキュリティパッチを含む)
- その他の関連アプリケーションソフトウェア
- AWS が提供するセキュリティグループファイアウォールの設定と管理
となります。
IAM (Identity and Access Management)
ここからは、AWSのサービスについて説明していきます。
IAMは、AWSのサービスやリソースへのアクセスを安全に管理するためのサービスです。
IAM自体は、無料です。
ここでの登場人物（キーワード）は、
- IAMユーザ
- IAMグループ
- IAMロール
- IAMポリシー
となります。
IAMユーザとIAMグループ
言葉だけでイメージはつきやすいのではないかと思います。
IAMユーザは、AWSを操作するための個別のアカウントです。
AWSをGUIで操作できる画面（マネジメントコンソール）にログインして、操作することができるユーザです。
初回利用時のAWSアカウントを作成すると、ルートユーザが作成されます。
このルートユーザは、使用しないことが推奨されています。
その名の通り、なんでもできちゃうユーザなので。
また、ルートアカウントを保護するために、多要素認証（MFA）を使用することができます。
MFAとは、通常のログイン認証に加えて、AWSでサポートしている認証機能を使用してセキュリティを高められます。
具体的には、MFA専用のアプリなどをスマホアプリに入れて、
PCなどでマネジメントコンソールなどにログイン認証した後、MFA専用のアプリで発行された番号をPCの画面上に打ち込んで認証することで、ログイン完了します。
こうすることで、ルートアカウントのログイン情報が盗まれても、MFAの情報が無いとログインが完了しません。
ですので、最初に、ルートユーザで適切なアクセス権限（IAMポリシー）を付与したIAMユーザを作成し、
それ以降は作成したIAMユーザで操作するようにしてください。
ユーザ認証では主に2種類どちらかを使用します。
一つ目は、コンソールパスワードです。コンソールパスワードは、AWSマネジメントコンソールにログインするためのパスワードです。
二つ目はアクセスキーです。用途は、AWSをプログラムから呼び出してリソースの操作することなどです。
アクセスキーは、「アクセスキーID」と「シークレットアクセスキー」の組み合わせとなります。
この2つのキーは、自分でcsvファイルとして保管しておく必要があります。
特に「シークレットアクセスキー」に関しては、初回生成時にcsvに出力させておかないと、
初回の生成画面を閉じると、二度と知ることができません。
AWSの推奨としては、頻繁にキーを更新してセキュリティを担保してくださいとのことです。
そのユーザたちをまとめることができるのが、IAMグループです。
ユーザは複数のグループに属すことができます。
ただし、グループの中にグループを作成することはできません。
IAMポリシーとIAMロール
つづいて、ポリシーとロールについてです。
ポリシーは、各アクションへのアクセス定義をします。
そして、それをIAM アイデンティティ (ユーザー、ユーザーのグループ、ロール) やAWSのリソースに対して、
紐づけて使用することが可能です。
各サービスに対して、フルアクセスや、読み書きどちらかを付与するポリシーを作成できます。
それをユーザやグループに紐づけることで、権限をコントロールすることができます。
このあたりは、Windowsでも同様の仕組みがありますよね。
さて、ロールです。聞きなじみはないですね。
僕もこの概念が出てくるたびに、「ん？」と理解し直します(笑)
間違いを恐れずに、僕自身の理解で説明すると、
ロールとは、ポリシーを集めたポリシー群みたいなものです。
具体的には、あるユーザにアタッチ（紐づけ）していたロールA（ポリシー群A）を、
別アカウントのロールB（ポリシー群B）に切り替えたいときなどに役立ちます。
一時的にロールを付与したり、切り替えたりが簡単にできます。
といったところです。この説明でお分かりいただけているだろうか。。
セキュリティグループ
セキュリティグループは、インスタンスの仮想ファイアウォールとして機能します。
通信の出入りをコントロールするためのものです。
（※各リソースやサービスの単位として、インスタンスとAWSでは頻繁に呼んでいます。）
セキュリティグループの作成時にルールを決めて、送信元のIPアドレスやIPアドレスの範囲と、
ポートやポート範囲を指定します。
このルールは、インバウンド（自分に入ってくる通信）と、アウトバウンド（自分から出ていく通信）に対して設定します。
AWS ShieldとWAF
AWS Shield
DDoS攻撃に対する保護機能です。
AWSには、AWS Shield Standard と AWS Shield アドバンスドが用意されていて、
Standardに関しては、無料で自動的に組み込まれています。
Standardでは主に、エッジロケーションのAmazon Cloud Front、DNS機能を持ったAmazon Route53などのサービスに対して、レイヤー3やレイヤー4に対しての攻撃が保護されます。
AWS Shieldアドバンスドは、EC2やAmazon Cloud Front、DNS機能を持ったAmazon Route53などのウェブアプリケーションを標的とした攻撃に対する高レベルな保護を実現します。
クラウドプラクティショナーの試験としては、すごい保護してくれるのがアドバンスドなのね、
くらいに思っていればよいと思います(笑)
ただ、Amazon Cloud FrontやAmazon Route53（これらは、今後紹介していきます）とセットで覚えておくとよいです。
WAF
Amazonのドキュメントを見ると、
AWS WAF は、Amazon CloudFront、Amazon API Gateway API、または Application Load Balancer に転送される HTTP(S) リクエストをモニタリングできるウェブアプリケーションファイアウォールです。
と書いてあります。
ややこしいので、試験に臨むにあたっては、さきほどのShieldよりも高レイヤーをモニタリングしてくれてるんだ！
くらいに解釈していればよいと思います。
Inspector
Amazon Inspectorは、ざっくりいうと脆弱性を教えてくれる機能です。
EC2（仮想マシン）たちのネットワーク観点の弱いところであったり、
各EC2で実行されるアプリケーションのセキュリティ状態をテストしてくれます。
それによって、Amazonのベストプラクティスとどれくらい離れているかを評価して、お知らせしてくれる機能みたいです。
とはいえ、最初に説明した責任モデルに基づいて、実際にセキュリティ設計して強化するのはユーザ側の責任です。
あくまでAWS側は、ここが危ないんじゃないかと教えてくれるだけです。
ちなみに、料金は 2 つの基準があって、Inspectorの評価に含まれる EC2 インスタンスの数と、
選択したルールパッケージのタイプによって決まるようです。
3章まとめ
3章のポイントをまとめます。
- AWSとユーザ側のセキュリティの境界線がある（責任共有モデル）
- IAMユーザ、グループ、ポリシー、ロールの違いを理解する（それぞれのどんな場面で使用するかイメージできるように）
- セキュリティを高めるためにAWS側でさまざまな機能、サービスを準備してくれているよということ（セキュリティグループ、Shield、WAFそしてInspector）
オンプレミスでもそうですが、特にAWSの設計・構築する上では、セキュリティやネットワークが大事になってきます。
だからセキュリティを強化するためにどんなサービスや機能があるか、どんなサービスを使用するべきかといった問題が出てくる印象です。
はい、では3章は以上となります。
また、次回以降もよろしくお願いします！
ここまで読んでいただき、ありがとうございます。少しでも参考になれば幸いです。
コメント