メモ
以前取得したAWSの資格「クラウドプラクティショナー」に続き「ソリューションアーキテクトアソシエイト(SAA-C03)」取得を目指して勉強中！
いつも何か勉強するときは基本的に書きながら覚えるのでここでアウトプットします。
有益な情報かどうかは不明(笑)
スポンサーリンク
セキュリティとアイデンティティ
AWSのアカウントの種類
AWSには「AWSアカウント」と「IAMユーザー」と呼ばれる2種類のアカウントがある。
AWSアカウントは、AWSへサインアップする時に作成されるアカウント。
このアカウントは、AWS全てのサービスをネットワーク上のどこからでも利用可能なため、そのユーザーはルートユーザーとも呼ばれる。
一方、IAMユーザーは、AWSを利用する各利用者向けに作成されるアカウント。
初期状態ではIAMユーザーは存在しない。
AWSアカウントでログインし、必要に応じてIAMユーザーを作成する。
また、複数のアカウントを管理するためのAWS Organizations(組織アカウント)という機能も追加されている。
組織アカウントを利用することで、複数のアカウントの請求をひとまとめにする一括決済が可能となっている。
さらに、利用可能なサービスをAWSアカウント単位で制限するサービスコントロールポリシー(SCP)も利用できるようになっている。
AWSアカウント
AWSアカウントのユーザーはルートユーザーとも呼ばれ、AWSの全サービスに対してネットワーク上のどこからでも操作できる権限を持っている。
非常に強力なアカウントであるため、取り扱いには十分注意する必要がある。
AWSでシステムを構築・運用する場合、AWSアカウントを利用することは極力避け、IAMユーザーを利用する。
また、AWSアカウント単位では、ルートユーザーにIPアドレス制限をするといった、利用シーンを制限する方法がない。
そのため、多要素認証(MFA)の設定などをしておくことを強くおすすめ。
IAMユーザー
IAMユーザーは、AWSの各利用者がWebコンソールにログインして操作する時や、APIを利用してAWSを操作する時などに使用する。
各IAMユーザーに対して、操作を許可する(しない)サービスが定義できる。
各IAMユーザーの権限を正しく制限することで、AWSをより安全に使用できる。
例えば、EC2インスタンスをStart/Stopする権限だけを与えて、TerminateはできないIAMユーザーを作成したり、ネットワーク(セキュリティグループやVPC、Route 53など)に関する権限のみを持つネットワーク管理者用IAMユーザーを作成したりできる。
IAMユーザーの管理はセキュリティの要になる。
VPCやEC2、S3をどんなにセキュアに保って管理していても、IAMユーザーは、それくらい重要なものだと心得る。
IAMにはユーザー以外にも様々な機能がある。
★AWSアカウントは非常に強い権限を持つので、このアカウントの利用は極力避け、IAMユーザーを使用する。IAMユーザーの権限を適切に制御することは、AWSシステムのセキュリティの要となる
IAMの機能
IAMの主要な機能は以下の4つがある。
・IAMポリシー
・IAMユーザー
・IAMグループ
・IAMロール
これらの機能を用いてユーザーに権限を付与するまでの流れは次のようになる。
1.AWSサービスやAWSリソースに対する操作権限をIAMポリシーとして定義する。
2.IAMポリシーをIAMユーザーやIAMグループにアタッチする。
3.IAMユーザーあるいはIAMグループに属するIAMユーザーがマネジメントコンソールにログインすると、付与された権限の操作を行うことができる。
IAMユーザーは、利用者を特定すること(Identity)を前提として利用する。
これに対してIAMロールは、必要に応じてどのような権限を付与するかという役割を与えるサービス。
どちらも重要なサービスのため、しっかりと理解する。
IAMポリシー
IAMポリシーは、Action(どのサービスの)、Resource(どういう機能や範囲を)、Effect(許可/拒否)という3つの大きなルールに基づいて、AWSの各サービスを利用する上での様々な権限を設定する。
このようにして作成されたポリシーをIAMユーザー、IAMグループ、IAMロールに付与することで権限の制御を行う。
インラインポリシーと管理(マネージド)ポリシー
IAMでは、ユーザーやグループ、ロールに付与する権限をオブジェクトとして管理することが可能で、これをポリシーと呼ぶ。
ポリシーには、インラインポリシーと管理(マネージド)ポリシーがある。
インラインポリシーは、対象ごとに作成・付与するポリシーで、複数のユーザー・グループに同種の権限を付与するには向いていない。
これに対して管理ポリシーは、1つのポリシーを複数のユーザーやグループに適用できる。
管理ポリシーには、AWS管理ポリシーとカスタマー管理ポリシーの2種類がある。
AWS管理ポリシーは、AWS側が用意しているポリシーで、管理者権限やPowerUser、あるいはサービスごとのポリシーなどがある。
一方、カスタマー管理ポリシーはユーザー自身が管理するポリシー。
記述方法自体はインラインポリシーと同じだが、個別のユーザー・グループ内に閉じたポリシーなのか共有できるかの違いがある。
なお、カスタマー管理ポリシーは、最大過去5世代までのバージョンを管理できる。
変更した権限に誤りがあった場合、即座に前のバージョンの権限に戻すといったことが可能。
使い分け方としては、AWS管理ポリシーで基本的な権限を付与し、カスタマー管理ポリシーでIPアドレス制限などの制約を行う。
インラインポリシーについては、管理が煩雑になるため基本的には使わないという方針で良い。
ただし、一時的に個別のユーザーに権限を付与する時に利用するといった方法が考えられる。
★インラインポリシーは、対象ごとに個別に適用する
★管理ポリシーは、複数のユーザー・グループにまとめて適用する
★AWS管理ポリシーはAWSによって用意されたもの
★カスタマー管理ポリシーはユーザー自身が管理する
IAMユーザーとIAMグループ
ユーザーとは、AWSを利用するために各利用者に1つずつ与えられる認証情報(ID)。
IAMユーザーと同義。
ここでの利用者には人だけではなく、APIを呼び出したりCLIを実行したりする主体も含まれる。
IAMユーザーの認証方法は次の2通り。
・ユーザーIDとパスワード：Webコンソールにログインするときに使用する。多要素認証(MFA)を組み合わせることを推奨
・アクセスキーとシークレットアクセスキー：CLIやAPIからAWSのリソースにアクセスする場合に使用する
一方、グループは、同じ権限を持ったユーザーの集まり。
グループはAWSのアクセス認証情報は保持しない。
認証はあくまでユーザーで行い、グループは認証されたユーザーがどういった権限(サービスの利用可否)を持つかを管理する。
グループの目的は、権限を容易かつ正確に管理すること。
複数のユーザーに同一の権限を個別に与えると、権限の付与漏れや過剰付与など、ミスが発生する確率が高くなる。
ユーザーとグループは多対多の関係を持つことができるので、1つのグループに複数のユーザーが属することはもちろん、1人のユーザーが複数のグループに属することもできる。
しかし、グループを階層化することはできないため、グループに一定の権限をまとめておき、ユーザーに対して必要なグループを割り当てる。
IAMロール
IAMロールは、永続的な権限(アクセスキー、シークレットアクセスキー)を保持するユーザーとは異なり、一時的にAWSリソースへのアクセス権限を付与する場合に使用する。
例えば以下のような使い方をする場合は、ロールを定義して必要なAWSリソースに対するアクセス権限を一時的に与えることができる。
ロールの考え方は少し複雑だが、上手に使いこなすことができれば非常に便利。
・AWSリソースへの権限付与：EC2インスタンス上で稼働するアプリケーションに一時的にAWSリソースへアクセスする権限を与えたい(EC2インスタンス作成時にロールを付与することで可能)
・クロスアカウントアクセス：複数のAWSアカウント間のリソースを1つのIAMユーザーで操作したい
・IDフェデレーション：社内のAD(Active Directory)サーバーに登録されているアカウントを使用して、AWSリソースにアクセスしたい
・Web ID フェデレーション：FacebookやGoogleのアカウントを使用してAWSリソースにアクセスしたい
ここでは、ポピュラーなEC2インスタンスにロールを付与して、インスタンス内のアプリケーションからAWSリソースにアクセスする方法を説明。
具体的な使用例として、EC2インスタンス上で稼働するアプリケーションからSESを使ってメール送信をする場合を想定する。
①まず最初はIAMロールを作成する。ロール作成時にEC2インスタンスだけがそのロールを取得できるロールタイプ(Amazon EC2ロール)を選択する。そしてロールに対して必要な権限(AmazonSESFullAccess)を付与する
②次に、作成したロールをEC2インスタンスに関連づける。複数のIAMロールを1つのインスタンスにアタッチすることはできないが、1つのIAMロールを複数のインスタンスにアタッチすることはできる
③②で作成したEC2インスタンス上でSESを使ったメール送信プログラムを稼働させる。このようなプログラムでは通常、SimpleEmailServiceクラスのオブジェクト生成時にアクセスキーとシークレットアクセスキーを認証情報として引数に渡すが、今回のプログラムではインスタンスに関連づけられたロールから認証情報を一時的に取得するため、これらのキーは不要
④SESへのアクセス権限をロールから一時的に取得したアプリケーションは、メールを配信することができるようになる
このように、インスタンスにロールを関連づけることで、プログラムや設定ファイルに認証情報(アクセスキー、シークレットアクセスキー)を記述する必要がなくなり、セキュリティの向上が見込まれる。
KMSとCloudHSM
機密性の高いデータを運用するには、暗号化の施策が必要になる。
その際に重要になるのが、暗号化や複合のための鍵の管理。
KMSやCloudHSMは、暗号化鍵の作成と管理のためのサービス。
アーキテクチャを検討する上でも、試験対策としても重要なサービス。
KMSとCloudHSM
AWSには鍵管理のサービスとして、KMSとCloudHSMがある。
CloudHSMは、VPC内で専有のハードウェアを利用して鍵を管理するサービス。
これに対してKMSは、AWSが管理するマネージドサービス。
両者の大きな違いは、信頼の基点がユーザー自身なのか、AWSに委ねるのかの違い。
CloudHSMは、専有ハードウェアを用いるため、初期コストも月次の固定費も必要。
そのため、よほど大規模なシステムや特定の規制・法令に準拠する目的以外では、利用するケースはなかなかない。
実際に使うケースはKMSの方が圧倒的に多くなる。
アーキテクチャ設計のポイントとしては、秒間100を超える暗号化リクエストがある、あるいは公開鍵暗号化を使いたい場合にはCloudHSMを利用し、それ以外にはKMSを使うという形になる。
★AWSの鍵管理サービスにはKMSとCloudHSMがある
★CloudHSMはVPC内で専有のハードウェアを利用して鍵を管理するサービスで、相当に大規模なシステムに用いる
★KMSは、AWSが管理するマネージドサービスで、多くの場合、CloudHSMではなくこちらを用いる
KMSの機能
KMSの主な機能は、鍵管理機能とデータ暗号化機能。
このうち、データ暗号化機能としては下記の3つのAPIがある。
・Encrypt
・Decrypt
・GenerateDatakey
Encryptは文字通りデータを暗号化するためのAPI。
4KBまでの平文データに対応している。
これに対してDecryptは複合化のためのAPI。
GenerateDatakeyは、ユーザーがデータの暗号化に利用するための、カスタマーデータキーを生成する。
平文の鍵と、Encrypt APIで暗号化された鍵を返す。
マスターキーとデータキー
KMSでは、主に2つの鍵を管理する。
マスターキーとデータキーで、AWSではCMKとCDKと表現されることが多い。
CMKは、データキーを暗号化するための鍵。
そして、CDKはデータを暗号化するための鍵。
KMSではデータの暗号化に際して、データキーでデータを暗号化してから、そのデータキーをマスターキーで暗号化する手法をとっている。
これは、データの保護のためで、この手法はエンベロープ暗号化と呼ばれている。
このような2層構造になっているのは、セキュリティ向上のため。
まずデータキーについては、基本的にS3やEBS、Redshiftなど、暗号化の対象ごとに作成する。
そうすることによりデータキーの漏洩の際のリスクを限定化する。
データキーをマスターキーで暗号化することにより、実際の運用で使う機会が多いデータキーを保護する。
そして、マスターキーを集中管理することにより、全体としてセキュリティを高めることができる。
★CMKはデータキーを暗号化するための鍵。CDKはデータを暗号化するための鍵
★KMSでは、データキーでデータを暗号化し、データキーをマスターキーで暗号化する(エンベロープ暗号化)
★エンベロープ暗号化によって、全体的なセキュリティが高まる
クライアントサイド暗号化とサーバーサイド暗号化
暗号化については、どこで暗号化するかという点も重要になる。
クライアントサイドで行うのか、サーバーサイドで行うのかということ。
クライアントサイド暗号化は、ユーザー側の処理で暗号化する方式。
多くの場合、AWSが提供するSDKを利用して行う。
EC2やLambda内のプログラムで暗号化してS3にアップロードした場合も、クライアントサイド暗号化になる。
ユースケースとしては、経路の安全性が保証されない場合はクライアントサイド側で暗号化したデータを送る。
これに対して、AWS側の処理で暗号化するのがサーバーサイド暗号化。
AWSのサービスが暗号化対応だという場合は、基本的に、サーバーサイド暗号化が用いられていることになる。
クライアントサイド暗号化のサービスは少なく、該当するのはS3などの一部のサービスのみ。
スポンサーリンク
AWS Certificate Manager
あらゆる情報がインターネットを介してやり取りされている現在、通信の暗号化は必須。
サーバーとのやり取りの暗号化、またそのサーバーの信頼性を確認するために、サーバー証明書が利用される。
その際に利用されるプロトコルがSSL/TLSで、SSL証明書と呼ばれることが多い。
なお、SSL証明書と呼ばれているが、SSL3.0を元にした後継プロトコルTLS1.0が制定されて以降、実際に利用されているのはTLS。
SSL3.0には脆弱性があるため、すでに非推奨となっている。
証明書の役割と種類
証明書を利用して実現できることは主に2つある。
1つは経路間の通信の安全性の確保。
これには、通信内容を盗聴されないようにするための暗号化と、通信内容の改ざんを防止することがある。
もう1つは通信している相手が誰かの照明。
本人性を照明するためには、信頼性が高い第三者が必要となる。
このためSSL証明書は、認証局(CA)という、証明書を管理する機関により発行されている。
証明の方法には次の4つの方法がある。
なお、証明の種類と暗号化強度の間に相関関係はない。
DVよりEVの方がより強い暗号が使われている、というわけではない。
・自己証明書：自分で認証局を立てて証明書を発行する(第三者による認証なし)
・ドメイン認証(DV)：ドメインの所有者のみを認証。組織情報の確認はされない
・組織認証(OV)：組織情報の審査を経てから認証する
・拡張認証(EV)；OVより厳格な審査で認証する。アドレスバーに組織名が表示される(最近のブラウザでは表示されなくなっている)
ACM
ACMは、AWS自身が認証局となってDV証明書を発行するサービス。
ACMは、2048ビットモジュールRSA鍵とSHA-256のSSL/TLSサーバー証明書の作成・管理を行うサービス。
ACMの証明書の有効期限は13ヶ月で、自動で更新するように設定することができる。
ACMを利用できるのはAWSのサービスのみだが、ACMには「無料」という非常に強いアドバンテージがある。
ACMの初期設定時には、ドメインの所有の確認が必要。
ドメインの所有の照明には、メール送信もしくはDNSを利用する。
連携可能なサービス
ACMは、AWSのサービスのみで利用できる。
2020年12月現在で利用可能なサービスは次の通り。
・ELB
・CloudFront
・AWS Elastic Beanstalk
・Amazon API Gateway
・AWS Nitro Enclaves
なお、Elastic Beanstalkは、サービス内で利用するELBに対して設定可能。
また、ELBのうち、ACMを利用可能なのはALBのみ。
★ACMは、AWS自身が認証局となって、RSA鍵とサーバー証明書の作成・管理を行うサービス。AWSのサービスから無料で利用できる
まとめ
・AWSアカウントは非常に強い権限を持つため、このアカウントの利用は極力避け、IAMユーザーを使用する。IAMユーザーの権限を適切に制御することは、AWSシステムのセキュリティの要となる。
・AWSの鍵管理サービスにはKMSとCloudHSMがある。CloudHSMは、VPC内で専有のハードウェアを利用して鍵を管理するサービスで、相当に大規模なシステムに用いる。KMSは、AWSが管理するサービスで、多くの場合、CloudHSMではなくこちらを用いる。
・ACMは、AWS自身が認証局となって、RSA鍵とサーバー証明書の作成・管理を行うサービス。AWSのサービスから無料で利用できる
