こんにちは、まなおです。
本日はAWSの資格取得に向けたサービスの復習記事です。
AWSにおいてセキュアにアプリケーションやサービスを作るために必要な10個のサービスについて、学習ポイントを整理しました（自分用メモ）。
後々文章として分かり易くリライトしていきます。
- ALB
- ALBのアクセスログを有効化することで、クライアントの接続情報を５分ごとに取得可能
- アクセスログ
- リクエストを受け取った時刻
- 発信元のIPアドレス
- レイテンシー
- リクエストされたパス
- デフォルトでは無効
- 有効化すると、ログのキャプチャをして暗号化し、S3バケットに保存（５分ごと）
- アクセスログ
- NLBの場合、TLSリスナーに対するリクエストのアクセスログを取得可能
- アクセスログの取得により、接続するクライアントについて、トラブルシューティングやトラフィックの分析が可能
- ALBのアクセスログを有効化することで、クライアントの接続情報を５分ごとに取得可能
- VPC
- VPCでインターネットのアクセスを構成する場合、IGWが必須
- ルートテーブルでは、宛先を0.0.0.0/0としたゲートウェイとして設定されていることが必要
- VPCサブネットのインスタンスに対するインターネットへのアクセス/インターネットからのアクセスでは次の点を確認
- IGWをVPCに接続
- サブネットのルートテーブルでIGW（0.0.0.0/0）を指す
- サブネットのインスタンスがグローバルIPを持つ
- ネットワークACLとセキュリティグループで関連トラフィックが疎通可能
- VPCサブネットのインスタンスに対するインターネットへのアクセス/インターネットからのアクセスでは次の点を確認
- VPC
- パブリック（0.0.0.0/0）からのHTTPSポート（443）の着信を許可するWebサーバとWebサーバからのMySQLポート（3306）の着信を許可するDBサーバのSGを設定
- SGはステートフルな設定なので、着信のみを設定すれば送信も制御される
- NACLはステートレスな設定なので、着信だけでは制御不可
- パブリック（0.0.0.0/0）からのHTTPSポート（443）の着信を許可するWebサーバとWebサーバからのMySQLポート（3306）の着信を許可するDBサーバのSGを設定
- VPC
- ２つの異なるVPC間は、VPCピアリングによって、同じネットワークのようにプライベートに接続可能
- VPCピアリング接続を設定すると、VPC内のインスタンスにパブリックIPアドレスは不要
- 同一アカウントのVPC間、別のAWSアカウントとのVPC間、別のAWSリージョンのVPC間に設定可能
- CIDRブロックが一致、または重複するVPC間の接続は不可
- ピアリング先を介して、その先のNWに接続することも不可
- ２つの異なるVPC間は、VPCピアリングによって、同じネットワークのようにプライベートに接続可能
- Redshift
- インターネットに出ないでS3とRedshiftを接続する際は、S3 VPCエンドポイントを構成し、Redshift拡張VPCルーティングを有効にする
- Redshiftの拡張VPCルーティングにより、Redshiftはクラスターとデータリポジトリ間のすべてのCOPYとUNLOADトラフィックを強制的にVPCにルーティングする
- 拡張VPCルーティングにより、VPCの標準機能であるSG、NACL、VPCエンドポイント、IGW、DNSサーバを使用できる
- インターネット経由しないでセキュアに接続可能で、かつきめ細かいVPC管理が可能になる
- 拡張されたVPCルーティングが有効でない場合、RedshiftはAWSネットワークにおけるその他のサービスへのトラフィックを含むトラフィックをインターネット経由でルーティングする
- Redshiftの拡張VPCルーティングにより、Redshiftはクラスターとデータリポジトリ間のすべてのCOPYとUNLOADトラフィックを強制的にVPCにルーティングする
- インターネットに出ないでS3とRedshiftを接続する際は、S3 VPCエンドポイントを構成し、Redshift拡張VPCルーティングを有効にする
- Cognito
- ユーザーは、Cognitoでユーザ名とPWを使用して直接サインインするか、Facebook/Googleなどを介してサインイン可能
- Cognitoのコンポーネント
- ユーザープール
- アプリユーザーのサインアップとサインインオプションを提供するユーザーディレクトリ
- ユーザープール
- Identityプール
- AWSの他のサービスに対するアクセスをユーザーに認可する
- 認証・認可例
- ユーザーがユーザープール経由でFacebook等にサインインする
- 認証OKであれば、ユーザーはユーザープールトークンを受領する
- Identityプールにおいて、ユーザープールトークンとAWS認証情報を交換する
- ユーザーは取得したAWS認証を用いてS3やDynamoDBなどAWSサービスにアクセスする
- Cognitoのコンポーネント
- ユーザーは、Cognitoでユーザ名とPWを使用して直接サインインするか、Facebook/Googleなどを介してサインイン可能
- Cognito
- ユーザによるアプリ認証にCognitoを使用するケースで、Open ID Connect（OIDC）IDプロバイダー（IdP）の認証を追加して、サインアップを省略可能
- IdPには、Google/FacebookなどのソーシャルIdP、SAMLベースのIdPプロバイダー、Salesforceなどが利用するOIDC IdPがある
- OIDC IdPのアカウントをすでに持つ場合、そのアカウントを利用してAWSサービスにCognito経由でサインイン可能
- 例：Salesforceのアカウントを利用し、サインイン可能
- 上記のようなサードパーティによるフェデレーションを利用したサインインは、ユーザープールで対応
- #6のソーシャル系サインアップと同様に、OIDCという標準化されたプロバイダーの認証をCognito認証に追加することができる
- ユーザによるアプリ認証にCognitoを使用するケースで、Open ID Connect（OIDC）IDプロバイダー（IdP）の認証を追加して、サインアップを省略可能
- IAM
- Lambda関数がDynamoDBテーブルにデータを書き込むためには、IAMロールがLambda関数にアタッチされていることが必要
- 上記は一例であって、あるAWSサービスが、別のAWSサービスにアクセスする際も同様
- アプリケーションへの認可についてはIAMロール（一時的な認可）の利用が適切
- IAMユーザーの利用も可能であるが、停止もありうるアプリケーションに対して、ユーザーとして常時認可を与えることは不適
- アクセスキー等を直書きしての認可も、セキュリティ事故につながる恐れがあるため不適
- Lambda関数がDynamoDBテーブルにデータを書き込むためには、IAMロールがLambda関数にアタッチされていることが必要
- IAM
- SQSキューなどのAWSリソースをアプリケーションで利用するためには、IAMロールがアプリケーションにアタッチされていることが必要
- IAMロールは、許可や禁止といったアクセス権限ポリシーが関連づけられているという点でIAMユーザーに近い
- しかし、IAMユーザーは特定の人にずっと権限を与えるもの⇔IAMロールには標準的な長期認証情報（PWやアクセスキーなど）は関連づけられない
- IAMロール用の一時的なセキュリティ認証情報が提供されるだけ
- IAMロールにより、AWSリソースに対して通常時はアクセス権のないユーザーやアプリケーションに対しい、必要に応じてアクセス権を提供可能
- IAMロールは、許可や禁止といったアクセス権限ポリシーが関連づけられているという点でIAMユーザーに近い
- SQSキューなどのAWSリソースをアプリケーションで利用するためには、IAMロールがアプリケーションにアタッチされていることが必要
- IAM
- クロスアカウントIAMロールを使用すると、別のアカウントを作成し、そのアカウントにAWSリソースへのクロスアカウントアクセスを認可できるため、サードパーティへの監査の委託にも利用可能
- クロスアカウントIAMロールにより、特定のアクセス許可を別のAWSアカウントに委任するロールを設定可能
- 例えば、サードパーティ等に監査アカウントを付与し、そのアカウントに監査が必要なアカウントへの許可を一時的に付与するIAMロールを使用し、安全にアクセスさせることが可能
- クロスアカウントIAMロールにより、特定のアクセス許可を別のAWSアカウントに委任するロールを設定可能
- クロスアカウントIAMロールを使用すると、別のアカウントを作成し、そのアカウントにAWSリソースへのクロスアカウントアクセスを認可できるため、サードパーティへの監査の委託にも利用可能
以上、まなおによる学習メモでした。