AWSクラウドプラクティショナー資格取得のための学習用備忘録(AWSのセキュリティ)

AWSの責任共有モデル

AWSとユーザーが責任を負う部分が明確に分かれ
それぞれがセキュリティを共有して守っていくことをAWS責任共有モデルと呼ぶ。

セキュリティには大きく分けて2つある。

1.クラウド本体のセキュリティ

AWSはクラウド本体のセキュリティ部分を担当する。

ハードウェアをはじめとしたAWSグローバルインフラストラクチャに含まれる
リージョンやAZ、エッジロケーションといったデータセンターの地域、
そしてマネージドなサービスのソフトウェアおよび、それに含まれる
各種サービスの管理(アップデートやセキュリティパッチのインストール)がAWSの担当。

AWSでは、ユーザーがAWSのセキュリティ管理フレームワークを最大限に活用できるよう
プライバシーおよびデータ保護における国際的なベストプラクティスを採用した
セキュリティ保証プログラムを策定している。

2.クラウド内のセキュリティ

ユーザーはクラウド内のセキュリティを担当する。

ユーザーの責任範囲としては、従来のデータセンターの場合と同じように
ゲストオペレーティングシステムの管理(アップデートやセキュリティパッチのインストール)、
そして関連アプリケーションソフトウェアの管理や
AWSより提供されるセキュリティグループファイアウォールの設定などが挙げられる。

さらに、ユーザーの責任範囲は、使用するAWSのサービス、
それらのサービスをユーザーのIT環境に統合する方法、適用される法規制に応じて異なる。

ユーザーが担当するクラウド内のセキュリティに関しては
容易に管理を行うことができるサービスやツールが提供されている。

★AWSはクラウド本体のセキュリティ部分を担当する。

★ユーザーはクラウド内のセキュリティを担当する。

★AWSが用意するセキュリティサービスを適切に活用して
ユーザーはクラウド内のセキュリティを管理できる。

AWSクラウドのセキュリティ

AWSセキュリティの利点は4つ。

1.データの保護：AWSインフラストラクチャには、ユーザーのプライバシーを保護するための強力な安全対策が用意されている。
全てのデータは安全性が非常に高いAWSデータセンターに保存される。

2.コンプライアンスの要件に準拠：AWSでは、インフラストラクチャ内で数多くのコンプライアンスプログラムを管理できる。
つまり、コンプライアンスの一部は最初から達成されている。

3.コスト削減：AWSデータセンターを利用することでコストを削減できる。
ユーザーが独自の施設を管理することなく、最上位のセキュリティを維持できる。

4.迅速なスケーリング：AWSクラウドの使用量に合わせてセキュリティをスケーリングできる。
ビジネスの規模にかかわらず、AWSインフラストラクチャによってユーザーのデータが保護される。

AWSが責任を持つ範囲の考え方

・物理的なセキュリティ

1.環境レイヤー

AWSは洪水、異常気象、地震といった環境的なリスクを軽減するために
データセンターの設置場所を慎重に選択している。
AWSの各リージョンにおけるデータセンター群は、互いにそれぞれ独立し物理的に分離されて配置されている。
こうした分離された配置構成の利点は、地震などの自然災害が特定のデータセンター群に影響を与えたとしても
処理中のトラフィックを影響のある地域から自動的に移動できること。

2.物理的な境界防御レイヤー

AWSデータセンターの物理的なセキュリティは、境界防御レイヤーから開始される。
このレイヤーはいくつもの特徴的なセキュリティ要素を含んでおり、
物理的な位置によって、保安要員、防御壁、侵入検知テクノロジー、監視カメラ、その他セキュリティ上の装置などが存在する。

3.インフラストラクチャレイヤー

インフラストラクチャレイヤーには、データセンターの建物、各種機器、
およびそれらの運用に関わるシステムが存在する。
発電設備や、冷暖房換気空調設備、消火設備などといった機器や設備は
サーバーを保護するために重要な働きをすることになるが
究極的にはユーザーのデータを保護することに役立っている。

4.データレイヤー

データレイヤーにはユーザーのデータを保持する唯一のエリアとなるため
防御の観点では最もクリティカルなポイント。
防御策は、アクセスを制限し、各レイヤーにおいて特権を分離することから始まる。
AWSは、このデータセンターをさらに保護するために、脅威検出機器やシステム的な手続きを備えている。

・ハイパーバイザーのセキュリティ管理

仮想化を実現するハイパーバイザーのセキュリティ範囲はAWSの担当。

AWSを利用する上で、各インスタンスは別のインスタンスのメモリを読み取ることも、
ハイパーバイザーのメモリを読み取ることもできない。

VMエスケープやクラウドバーストVMエスケープ、VMホッピングなどの
ハイパーバイザーをターゲットとした各種攻撃に関してはAWSが対応している。

米Intelが発表したプロセッサの重大な脆弱性や、プロセッサの投機的実行の機能に関する脆弱性に関しても
AWSハイパーバイザー上で解決している。

また、準仮想化(PV)インスタンスに関しても、最新のAMIのイメージの提供や更新パッケージを提供している。

★AWSのデータセンターのセキュリティはAWSの担当。

★ハイパーバイザーのセキュリティはAWSの担当。

・管理プレーンの保護

管理プレーンの保護に関するセキュリティの範囲はユーザーの担当。

具体的にはIDとパスワード、キーペア、APIキーの管理、アクセス制御と権限管理。

IDとパスワード：AWSでは、MFA(多要素認証)デバイスの利用が可能。
AWSサインアップ時に作成したルートアカウントなど、
権限の強いアカウントにはMFAなどを設定し、アカウントの保護を行う。

ルートアカウント：AWSサインアップ時に作成したメールアドレスのアカウント。
ルートアカウントから権限を外すことはできないため、
日常の操作にはルートアカウントを利用せず、
適切な権限のみを付与したユーザーを作成し、それを利用すべき。
ユーザーは1アカウント内に複数作成可能。

キーペアの作成：キーペアはEC2などのインスタンスへのログインで利用する。
昔はサーバーへのログインには「ユーザー名＋パスワード」によって認証を行なっていたが、
現在ではセキュリティを高めるために、公開鍵認証方式を用いたキーペアによってログイン認証を行うのが一般的。

キーペアの秘密鍵の管理はユーザーの責任で、AWSでは秘密鍵の管理を行わない。

秘密鍵を紛失してログインできなくなってもAWS側で鍵のリセットは行えず
プライバシーの関係上、EC2インスタンス自身のデータにアクセスできるのはユーザー自身のみ。
キーペアの管理は、部署で共有して利用している会社もあるが
特性上、秘密鍵を共有で利用するのは好ましくない。
利用者ごとにキーペアを生成し、利用者ごとの公開鍵をサーバー(EC2などのインスタンス)に設定するのが良い。

APIキーの管理：APIキーはユーザーの責任。
コマンドライン操作をするCLIやプログラム上で利用する際にはAPIキーを利用する。
APIキーは、アクセスキーとシークレットアクセスキーのペアで構成される。

各ユーザーは、アクセスキーとシークレットアクセスキーを作成・保持することができる。
このペアをコマンドライン操作やプログラムの認証情報として利用できる。
アクセスキーとシークレットアクセスキーの値を環境変数や認証ファイル内に格納して利用する。

アクセスキーとシークレットアクセスキーは、IDとパスワードと同等のもので
各ユーザーに対して発行できる。
そのため、権限の強いアカウントからAPIキーを生成しないようにする。
必ず、そのCLIで利用する範囲の権限や、プログラム内で必要な権限のみを付与する。

プログラム内のソースコードにAPIキーを埋め込むのはセキュリティの観点から好ましくない。
環境変数や認証ファイルに書き出し、適切な権限づけを行い、定期的にAPIキーを入れ替えて運用するのが良い。

現在では、認証情報の更新の問題や流出の危険性などからAPIキーの利用は推奨されていない。
IAMロールといった、AWSの各種リソースに対するアクセス可否(IAMポリシー)を利用することが推奨される。

★管理プレーンの保護はユーザーの担当。

★IDとパスワードはユーザーが適切に管理する。権限が強いアカウントにはMFAを組み合わせて利用する。

★キーペアはユーザーが適切に管理する。

★APIキーはユーザーが適切に管理する。必要最低限の権限のみを付与する。

★ルートアカウントのAPIキーは作成しない。

・マネージドでないサービスのセキュリティ

EC2やVPCなど、IaaSに分類されるAWSサービスは
ユーザーが管理者権限やルート権限を持ち全てを管理するため、
ユーザーは必要なセキュリティ設定と管理タスクをすべて実行する必要がある。

例えば、EC2インスタンスの場合、ユーザーは、ゲストOSの管理や
インスタンスにインストールするすべてのアプリケーションソフトウェアまたはユーティリティ、
各インスタンスでAWSにより提供されるファイアウォール(セキュリティグループ)の設定に対する責任を負う。
これらの作業は、サーバーがどこにあるかに関わらず、
ユーザーがオンプレミスのシステム上でこれまで実行してきたセキュリティタスクと基本的に同じ。
もちろん、マネージドでないサービス上に置くユーザーのデータやコンテンツなどの管理もユーザーの責任。

★マネージドでないサービスのセキュリティの責任については、ユーザーが操作できる部分はすべてユーザーの責任。

★ユーザーが操作できるマネージドでない部分は、オンプレミスのシステムで行ってきたことと同等。

★EC2などのコンピューティングサービスは、OS層以上はユーザーの責任。

★ファイアウォール(セキュリティグループ)の設定内容は、ユーザーの責任。

・マネージドなサービスのセキュリティ

DBサービスのRDSやdynamoDBなどはマネージドなサービス。
OSやDBのパッチ適用、ファイアウォールの設定、災害対策といった
ユーザーからは直接見えない部分のセキュリティ対応に関してはAWSが行う。
ユーザーはプラットフォームで実行する内容に集中できる。

ほとんどのマネージドサービスの場合、リソースへのアクセスコントロールの設定と、
アカウント認証情報の保護のみがユーザーの責任範囲。
一部のマネージドサービスでは、DBのユーザーアカウントの設定といった追加作業が必要になる場合があるが
多くの場合、セキュリティの設定は自動的に実行される。

AWSがクラウドのインフラのメンテナンスと保護を行うのに対し、
ユーザーはクラウド上に保存するあらゆるものを保護する責任を負う。
AWSのサービスを利用する場合、そのコンテンツはすべてユーザーが管理して制御する。
またユーザーは、コンテンツを保護するための重要な要件を満たす責任を負う。

★マネージドなサービスの責任は、ユーザーとAWSでそれぞれが分担。

★サービスのプラットフォーム部分はAWSの責任。

★サービスのプラットフォーム上のデータや、その上に置くアプリケーションはユーザーの責任。

★サービスにアクセスするためのアクセスコントロール設定とアカウント認証情報の保護は、ユーザーの責任。

★マネージドでないサービスより、ユーザーのセキュリティに関する負担は軽減。

・セキュリティのベストプラクティス

ユーザーが責任を負う部分には、セキュリティのベストプラクティスが4点ある。

1.転送中データの保護：適切なプロトコルおよび暗号化アルゴリズムを選択。
特にEC2などのマネージドでないサービスを利用する場合、ユーザーはサーバー上の通信を自由に選択できる。
(FTPのように、パスワードが暗号化されることなくそのままの状態で通信されるプロトコルも選択可能)
しかし、インターネットを介した通信の場合は、第三者からその通信内容を秘匿する必要があるため、
SCPなどの暗号化されたプロトコルを選択する。また、脆弱性のある暗号化アルゴリズムを選択することも避ける。

2.蓄積データの保護：蓄積データの物理的な保護はAWSが行ってくれるが、
運用上データベースやストレージの内容を出力することがある。
この際に、意図しないところで、個人情報に権限のないスタッフにもアクセス可能な状態になることがある。
蓄積データの保護の例としては、DBの登録時にアプリケーション上でのデータ暗号化を行うことが望ましい。
システムのコンプライアンス上の要件に応じて、データの暗号化を行う。
AWSのマネージドなサービスでは、ストレージやDBの暗号化オプションがある。これらを有効活用するのも良い。

3.AWS資格情報の保護：ルートアカウントを使用せずに、ユーザーごとにIAMユーザー作成し、
必要な業務内容や機能を実行するために必要な最小限の権限を付与する。

4.アプリケーションの安全性の確保：実行するアプリケーションの安全性を確保するためには、
SQLインジェクション、OSコマンドインジェクション、クロスサイトスクリプティングなど、
既知の攻撃に対する対応を行う。
IPAやCSAといった団体から出ている脆弱性関連情報をチェックし、
Amazon Inspectorなどを活用し、定期的な脆弱性診断を行うことが望ましい。

★転送中データを保護するには、適切なプロトコルおよび暗号化アルゴリズムを選択する。

★蓄積データを保護するには、コンプライアンス要件に従い暗号化を行う。AWSの提供する暗号化オプションを活用する。

★AWS資格情報を保護するには、適切なユーザーの作成と、必要最低限の権限設定を行う。

★アプリケーションの安全性を確保するには、定期的な脆弱性診断と脆弱性情報の確認、アプリケーションの改善を行う。

・第三者認証

ユーザーは、AWSのデータセンターやオフィスを訪問して、インフラが保護されている様子を直接見ることはできない。
しかしAWSは、コンピュータのセキュリティに関する様々な規格や規制に準拠しているかどうかについて
第三者の監査機関により検査を受けており、そのレポートをAWS Artifactにて提供している。

AWSがユーザーに提供するITインフラは、セキュリティのベストプラクティス、
および各種ITセキュリティ基準に合わせて設計、管理されている。
AWSが準拠している保証プログラムの一部：CSA、ISO9001,27001,27017,27018、PCI DSS レベル1、SOC1、SOC2、SOC3

日本でビジネスを行う上で必要な認証も取得している。
FISC、IRAP、K-ISMS、MTCS ティア3、マイナンバー法、FInTech、医療情報ガイドライン、NISC

IAM

IAMは、ユーザーのAWSクラウドリソースへのアクセス管理サービス。

AWSのユーザーとグループを作成および管理し、アクセス権を使用してAWSリソースへのアクセスを許可および拒否できる。

AWSサインアップした時に作成したアカウントはルートアカウントと呼ばれ、全ての権限を持っている。

IAMでは、AWSアカウント内にIAMユーザーやIAMグループを作成することができる。

IAMユーザーごとに、AWSの各種リソースに対するアクセス権を設定でき、IAMユーザーに対してAPIキーも作成できる。

・IAMグループとIAMユーザー

IAMで作成したIAMグループとIAMユーザーには、最初は権限が与えられていない。
そのため、アクセスの割り当てを行うが、必要最低限の権限を割り当てるようにする。

アクセス権限に関しては、許可と拒否の設定を行うことができる。
これらが相反するときは拒否が優先される。

APIキーは1人のIAMユーザーに2つまで発行できる。
これは、キーの入れ替えを行う際に、
全ての入れ替えが終わるまでにアプリケーション側に権限がなくなってしまうのを防ぐため。

新APIキーを発行して、旧APIキーが設定されているアプリケーションを順次入れ替えていく。
全てのアプリケーションに対して新APIキーの設定が完了したら旧APIキーをIAM上で削除する。
こうして定期的なAPIキーの更新を行う。

APIキーはアクセスキーとシークレットアクセスキーのペアで構成される。

IAMでAPIキーを生成する際、アクセスキーはいつでも確認ができる。
しかし、シークレットアクセスキーは生成時しか確認できない。
シークレットアクセスキーが不明になった場合は、APIキーを新たに生成する必要がある。

EC2インスタンスのキーペアと同様に、シークレットアクセスキーもしっかりと管理を行うこと。

IAMロール

現在APIキーの使用は推奨されていない。これを解決するためにIAMロールを利用する。

IAMロールは、EC2やLambdaなどのAWSリソースに権限を付与することができる。
このメリットは、AWSの内部でIAMロールとEC2を直接紐づけることができるため、キーを管理する必要がない。

AWS Directoruy ServiseでIAMロールを使用することで、SSO構成にすることもできる。

★各IAMユーザー、IAMグループには、必要最低限の権限を付与する。

★IAMポリシーが相反するときは、拒否が優先される。

★IAMユーザーには、最大2つのAPIキーが発行される。

セキュリティグループ

セキュリティグループは、1つ以上のインスタンスのトラフィックを制御する仮想ファイアウォール。

・ファイアウォールとセキュリティグループ

従来のオンプレミスシステムでは、中央集権的なファイアウォールを1つ、
外部のネットワーク(インターネットなど)の前に設置していた。
理想系としては、それぞれのノード(サーバやDBインスタンス)ごとに設置できることが望ましいが、
コスト的にもラックのスペース的にも難しかった。

AWSでは、各インスタンスごとに個別のファイアウォール設定を行えるセキュリティグループという機能がある。
セキュリティグループ設定は、その名の通りグループとして利用でき、
同一の目的で利用するサーバー群に対して同一の設定を適応することも可能。

セキュリティグループで行える設定

・許可ルールの指定が可能

・拒否ルールの指定は不可能

・インバウンドトラフィックとアウトバウンドトラフィックのルールを個別に指定可能

セキュリティグループを新規作成する際、インバウンドルールはない。
したがってインバウンドルールをセキュリティグループに追加するまで、
別のホストからインスタンスに送信されるインバウンドトラフィックは許可されない。

デフォルトでは、セキュリティグループにはすべてのアウトバウンドトラフィックを許可する
アウトバウンドルールが含まれている。

セキュリティグループはステートフル。インスタンスからリクエストを送信する場合、
そのリクエストのレスポンストラフィックは、インバウンドセキュリティルールにかかわらず許可される。

AWS ShieldとAWS WAF

AWS Shield

AWS Shieldはマネージド型の分散サービス妨害(DDos攻撃)に対する保護サービス。
AWSで実行しているWebアプリケーションを保護してくれる。

DDos攻撃はネットワークのトラフィック(通信量)を増大させ、
通信を処理しているコンピューティングサービス(通信回線やサーバーの処理能力)に負荷をかけることによって、
サービスを利用困難にしたり、ダウンさせたりする攻撃。
これはDos攻撃を発展させたものであり、
攻撃元が他の複数のコンピュータを乗っ取り、ターゲットに対して一斉に攻撃するのが特徴。

これらの攻撃には大きく分けて、単純にアクセスを極端に増やして回線の帯域自体に負荷をかける方法と、
サーバーやアプリケーションのセキュリティホールを狙った攻撃を行い、
サーバーなどのサービスのインフラ環境に負荷をかける方法とがある。

AWS Shieldは、アプリケーションのダウンタイムとレイテンシーを最小限に抑える
常時稼働の検出と自動インライン緩和策を提供している。

AWS Shieldには「Standard」と「Advanced」の2つのレベルでのサービスがある。

すべてのAWSユーザーは、追加料金なしでAWS Shield Standardの保護の適用を自動的に受けることができる。
AWS Shield Standardでは、Webサイトやアプリケーションを標的にした、
最も一般的で頻繁に発生するネットワークおよびトランスポートレイヤーのDDos攻撃を防御する。

従来のオンプレミスのシステムでは、DDos攻撃のためにDDos対策機器の購入及び選定にかなりの投資を行っていた。
これらを無料で利用することが可能。
また、攻撃通知や分析、レポート生成に工数を割かれていたが
有償のAWS Shield Advancedを選択することで、これらの業務をDDos Response Teamにアウトソースすることが可能。

さらにAWS Shield Advanced選択すると、AWS WAFサービスが無償で無制限に利用可能となる。

★AWS Shieldはマネージド型のDDos攻撃に対する保護サービス。

★AWS Shield Standardは一般的なDDos攻撃からAWS上のシステムを保護する。

★AWS Shield Advancedは、Standardに加えて、DDos Response Teamによる緩和策を実施し、攻撃を可視化する。

★AWS Shield Advancedでは、AWS WAFが無償で無制限に利用可能。

AWS WAF

AWS WAFは、アプリケーションの可用性低下、セキュリティの侵害、リソースの過剰消費などの
一般的なWebの脆弱性からWebアプリケーションを保護する、マネージド型のWebアプリケーションファイアウォール。

Web サイト上のアプリケーションに特化したファイアウォールで
主にユーザーからの入力を受け付けたり、リクエストに応じて動的なページを生成したりするタイプのWebサイトを
不正な攻撃から守る役割を果たす。

一般的なファイアウォールとは異なり、データの中身をアプリケーションレベルで解析できるのが特徴。

Webサイト上のアプリケーション自体にセキュリティ上の問題があってもそれを無害化できるという利便性の高さと、
ISMSの実現やPCI DSSへの準拠といった企業の情報戦略面のニーズから、
オンプレミスの頃からその導入意義が注目されていた。

AWS WAFの基本利用料は無料だが
従来オンプレミスで提供されてきた日本のWAFサービスのように、あらかじめWAFの定義は入っていない。

どのトラフィックをWebアプリケーションに許可、
またはブロックするかのWAFの定義をユーザー自身で行う必要がある。

SQLインジェクションまたはクロスサイトスクリプトのような一般的な攻撃パターンをブロックするカスタムルール、
および特定のアプリケーションのために設計されるルールをAWS WAFに作成できる。

課金は、ユーザーが作成するカスタマイズ可能なWebセキュリティルールの指定に基づいて行われる。

・Webアクセスコントロールリスト(Web ACL)数に基づく課金方法

・Web ACLごとに追加するルール数に基づく課金方法

・受け取るWebリクエスト数に基づく課金方法

AWS WAFに設定したルールは数分以内にデプロイされ、トラフィックパターンの変化にすばやく対応が可能。

また、AWS WAFにはフル機能のAPIが含まれている。
このAPIにより、Webセキュリティルールの作成、デプロイ、メンテナンスを自動化することができる。
例えば、自分自身でWAF定義を行ったことがない人は、
サードパーティ(AWSパートナー企業など)が提供するWAF定義提供サービスを利用し、
従来のオンプレミスのWAFのようにWAF定義導入済みの状態で利用することができる。
これらWAF定義設定サービスは、AWS WAFのAPIを利用してWebセキュリティルールを設定している。

AWS WAFの適用範囲

Web ACLでの AWS WAFの適用サービスは、
CDNサービスのCloudFront、ロードバランサーのALB、API Gatewayから選択する。

API Gateway：APIの運用管理の手間から解放されるフルマネージメントのサービス。
独自のRESTおよびWebSocket APIの作成、公開、保守、モニタリング、保護が簡単にでき、
AWSまたは他のWebサービス、AWSクラウドに保存されているデータにアクセスできる。

★AWS WAFはマネージド型のWebアプリケーションファイアウォールサービス。

★AWS WAFの基本利用料は無料。Webセキュリティルールに基づいて課金される。

★AWS WAFのWebセキュリティルールはユーザーが設定する必要がある。

★Web ACLの適用サービスは、CloudFront、ALB、API Gatewayから選択する。

Inspector

Amazon InspectorはAWSのEC2の上にデプロイされたアプリケーションの
セキュリティとコンプライアンスを向上させるための、脆弱性診断を行うことができるサービス。

Inspectorは自動的にアプリケーションを評価し、脆弱性やベストプラクティスからの逸脱がないかどうかを確認する。

評価が実行された後、重大性の順に結果を表示した詳細なリストがInspectorによって作成される。

Inspectorを使用すると、開発及びデプロイパイプライン全体で、または静的な本番システムに対して、
セキュリティ上の脆弱性の評価を自動化することができる。
この機能により、開発やIT運用の一環として、セキュリティテストをより定期的に実行できるようになる。

Inspectorは、エージェントベースおよびAPI主導のサービスとして提供され、デプロイ、管理、および自動化を容易にする。

Inspectorには、すぐに利用を開始できるよう、
共通のセキュリティベストプラクティスや脆弱性の定義に対応した、何百もの収められたナレッジベースが備えられている。
組み込まれたルールの一例として、リモートルートログインが有効になっているかどうか、
または脆弱なソフトウェアがインストールされていないかどうかをチェックするものがある。
これらのルールはAWSのセキュリティ研究者によって定期的に更新される。

Inspectorによって診断が行える事項

・一般的な脆弱性や漏洩

・ネットワークセキュリティにおけるベストプラクティス

・認証におけるベストプラクティス

・OSのセキュリティにおけるベストプラクティス

・アプリケーションセキュリティにおけるベストプラクティス

・PCI DSS 3.0アセスメント

例えば、PCI DSSを取得している企業では脆弱性管理プログラムの整備が必要となっているが、
PCI DSSのルールパッケージを利用してスケジュール設定により自動でチェックを行うことができる。

PCI DSS：クレジットカード会員の情報を保護することを目的に定められた、
クレジットカード業界の情報セキュリティ基準。
2004年に国際カードブランド5社によって策定された。
現在は5社が共同設立した組織であるPCI SSCによって管理運営されている。

AWS Artifact

AWSのコンプライアンスにオンデマンドでアクセスできる無料のセルフサービスポータルがAWS Artifact。

SOC、PCIレポートなどが取得可能。

AWS Key Management Service(KMS)

AWS上で暗号化キーを簡単に作成・管理し、幅広いAWSのサービスやアプリケーションでの使用を制御できるサービス。

AWS CloudTrailと統合されており、すべてのキーの使用ログを表示できるため、規制及びコンプライアンスの要求にも対応可能。

★Amazon Inspectorは脆弱性診断を自動で行うことができるサービス。

★EC2上のデプロイされたアプリケーションに対応。

★各種ルールパッケージはAWSが最新のものにアップデート。

★スケジューリング機能により、完全に自動でチェック可能。

★AWSのコンプライアンスレポートを取得するには、AWS Artifactからダウンロードする。

★KMSは、AWS上で暗号化するためのキーを作成・管理し、暗号化の制御が行えるサービス。

まとめ

・AWSはクラウド本体のセキュリティ部分を担当し、
ユーザーはクラウド内のセキュリティを担当する(クラウドセキュリティの責任共有モデル)　。

・Amazon EC2やAmazon VPCなど、Iaasのカテゴリーに分類されるAWS製品はユーザーがすべてを管理するため、
ユーザーは、必要なセキュリティ設定と管理タスクをすべて実行する必要がある。

・AWSは、ユーザーがクラウドにおけるセキュリティ対策を行う上で便利なツールやサービスを提供する。

・AWSセキュリティには、データ保護、コンプライアンス要件への準拠、コスト削減、迅速なスケーリングという4つの利点がある。

・IAMとは、ユーザーのAWSクラウドリソースへのアクセス管理サービス。I
AMでIAMユーザーやIAMグループを作成し、適切なアクセス権限を割り当てる。

・セキュリティグループは、1つ以上のインスタンスのトラフィックを制御する仮装ファイアウォール。

・AWS Shieldは、マネージド型のDDos攻撃に対する保護サービス。

・AWS WAFは、アプリケーションの可用性低下、セキュリティの侵害、リソースの過剰消費などの一般的なWebの脆弱性から
Webアプリケーションを保護する、マネージド型のWebアプリケーションファイアウォール。

・Amazon Inspectorは、脆弱性診断を自動で行うことができるサービス。