セキュリティ
早引き
- 認証を安全に行う方法
- KMSで暗号化した認証情報を埋め込む
- Secrets Managerによるシークレット情報の管理
- Systems Managerのパラメータストアによる認証情報の一元管理
- KMSは認証のための暗号化キーを生成するサービス。認証情報は管理しない。
- Secrets Managerは認証情報を管理するサービス
- 監査を行うサービス:
- AWS Config:AWSリソースの設定を監視する
- Cloud Trail:ユーザーの操作を監視
- Cloud Watch:AWSリソースのメモリなどを定期的に監視する(セキュリティ用ではない)
- (例)AWS Configで違反項目を検出した後、CloudTrailにより誰が対象のリソースを変更したのかを調べる
- セキュリティグループで設定できるのは許可ルールのみ。特定IPアドレスを拒否するルールの作成はできない
- セキュリティグループやネットワークACLはAWSリソースや機器を保護するもの。データそのものの保護は暗号化などを駆使する。
- Amazon RedshiftをVPC外のS3に対してアクセスするときは、拡張VPCルーティングを利用する
- S3バケットのオブジェクトはライフサイクルポリシーによって削除することができる。
- 特定地域の通信を拒否する:
- WAFの地理的制限
- Route53の位置情報ルーティング
- EC2をプライベートサブネットに置きつつ、インターネットに接続したい:
- ALBをパブリックサブネットに配置
- インターネットに接続せず、VPC内外のリソース間で接続したい:
- VPCエンドポイントを利用する
- PrivateLinkサポートがされているサービスが対象
- ゲートウェイ型とインターフェース型がある。ほとんどのサービスはインターフェース型を利用する
- ゲートウェイ型はS3とDynamoDBのみに対して使える。DynamoDBを使う場合はこっちを使う。ルートテーブルの宛先として使う。
- インターフェース型はIPアドレスを指定することで接続することができる。
- VPCエンドポイントを利用する
セキュリティグループとネットワークACL
セキュリティグループ
- 適用範囲:サーバー単位
- 状態管理:ステートフル(インバウンドが許可されればアウトバウンドも許可される)
- 設定方法:許可のみ、In/outで指定
- デフォルト:同じセキュリティグループ内通信のみ許可
- すべてのルールを適用
ネットワークACL
- 適用範囲:VPC/サブネット単位
- 状態管理:ステートレス(インバウンドが許可されてもアウトバウンドが許可されるとは限らない、両方の設定が必要)
- 設定方法:許可・拒否、In/outで指定
- デフォルト:すべての通信を許可
- 番号の順序通りに適用
AWS Site-to-Site VPN(サイト間VPN)
- カスタマーゲートウェイ(オンプレミスのルーター)とVPCの仮想プライベートゲートウェイ(VGW)を、インターネットVPNで接続するサービス
- インターネット上に仮想の専用線であるVPNトンネルを張り、IPsecという暗号技術を使って通信を保護する
AWS Site-to-Site VPNでの高可用性の実現
- 使用する仮想プライベートゲートウェイとVPNトンネルは、機器障害に対する高可用性を保つためにAWS側で冗長化されている
- 一方、カスタマーゲートウェイはオンプレミス内の機器なので、高可用性を保つにはAWSユーザー側で冗長化する必要がある
AWS Site-to-Site VPNのネットワーク監視
- VPNトンネルを経由したネットワークトラフィック情報は、Amazon CloudWatchで収集可能
- CloudWatchには指定した仮想プライベートゲートウェイのVPNトンネルの状態、送受信したバイト数が記録される
- VPNトンネルの状態をCloudWatchで監視すれば、VPNトンネルに異常が発生した場合にアラームを出すことができる
ネットワークACL
- ネットワークACLはVPC上でネットワークアクセスをサブネットごとに制御するファイアウォール
- IPアドレスを元に許可ルールと拒否ルールの両方を設定可能
- ルールはユーザーが付与したルール番号の順番に評価され、ルール間で矛盾がある場合は小さい数字のルールが適用される
- デフォルトの設定ではインバウンド通信(外部から内部への通信)、アウトバウンド通信(内部から外部への通信)ともにすべての通信が許可
Lambda関数
- lambda関数は、Lambda専用のセキュアなVPCに配置されている
- このLambda専用のVPCからは、インターネットや、インターネットを経由してパブリックサブネット内のAWSリソースにはアクセスできる
- パブリックに公開されていないAWSリソースへはアクセスできない
- Lambda関数からAWS Site-to-Site VPN経由でオンプレミスのデータベースにアクセスするには、Lambda関数をVGWが接続されているVPCに関連付ける「VPCアクセス」の設定が必要
- VPCアクセスを設定すると、Lambda関数に関連付けたVPCのサブネットに接続用のENI(Elastic Network Interface)を作成してサブネットへアクセスできるようになる
- VPCアクセスを設定したLambda関数は、ENIを作成したサブネットへアクセスできるようになる代わりに、インターネットへアクセスできなくなる
- サーバーやデータベースへアクセスする際、認証が必要になるケースがあります
- このとき、ユーザーIDやパスワードなどの認証情報はソースコードに埋め込む(ハードコーディング)するべきではない
- ではどうする? -> KMSを利用する
- Lambda関数にKMSで暗号化した認証情報を埋め込む
- 関数呼び出し時に、認証情報を復号する
AWSのリソース保護
AWS WAF
- 脆弱性を突く攻撃(クロスサイトスクリプティングやSQLインジェクションなど)から、Webアプリケーションを保護するサービス
- Web ACLというアクセスコントロールリストで、IPアドレス、HTTPヘッダー、HTTP本文、URI文字列などに対してフィルタリングの条件を設定できる
- 接続元のIPアドレスから国別にアクセスを制限できる機能がある
- Amazon CloudFront、Application Load Balancer、Amazon API Gatewayなどに割り当てて利用可能
- NLBはサポートしていない
- S3を直接保護することはできない。CloudFrontを経由する必要がある。
AWS Shield
- DDoS攻撃からの保護に特化したサービス
- ネットワークを保護する
- API Gatewayはサポートしていない
- すべてのAWSユーザーが無償で利用できる「AWS Shield Standard」と、有償版の「AWS Shield Advanced」がある
AWS Shield Standard
- ネットワーク層およびトランスポート層への一般的なDDoS攻撃からAWSリソースを保護
- デフォルトで有効
AWS Shield Advanced
- EC2インスタンス、Elastic Load Balancing、Amazon CloudFrontなどを標的としたDDoS攻撃に対して、高度な保護サービスが利用可能
- 高度化された大規模な攻撃からの保護
- DDoS攻撃発生時のモニタリングやレポート
- AWSのDDoS対応チームによるサポート
- 攻撃によって増加したAWS利用料金の補填
- etc…
暗号化
- データの暗号化・復号はサーバーまたはクライアントのいずれかで行われる
- サーバー側の暗号化(Server-Side Encryption:SSE)は、AWS(サービス提供側=サーバー側)にデータが保存されるタイミングで暗号化が行われる
- ユーザーがデータを取り出す際もサーバー側が復号して渡す
- クライアント側の暗号化は、サーバーへデータを送信する前にクライアント側で暗号化を行う
- サーバー側では受け取ったデータをそのまま保存します。また、データの復号もクライアント側で行う
- AWS側で暗号化が行われる場合はほとんどがサーバー側の暗号化
- クライアント側の暗号化は、通信回線のセキュリティに不安があるなどユーザーが自主的に暗号化したいケースで使用される
- クライアント側の暗号化は、暗号化および復号をユーザー側で行うため、鍵の利用状況のチェックや監査などもユーザー自身が行う必要がある
- クライアント側の暗号化を行うにはAWS SDKを使用する
AWS KMS(Key Management Service)
- 暗号化に使用する鍵(キー)を作成・管理するサービス
- エンベロープ暗号化方式を使っている
- 2段階で鍵を保護する方式のこと
- KMSでは、「KMSキー」「データキー」と呼ばれる2種類の鍵を使用してデータの暗号化および復号を行なっている
- 「KMSキー」はデータキーを暗号化する際に使用し、「データキー」はデータを暗号化するために使う
- データキーは通常、暗号化を行う対象のサービスごとに作成 -> 1つのデータキーが漏出しても他のサービスに影響が出ない
- 通常は、暗号化を行う対象のサービス(Amazon S3やEBS、Redshiftなど)と連携して利用する
- AWS CloudTrailと連携しており、鍵の使用ログ(いつどのサービスで鍵が使用されたか)が記録されるため、鍵の利用状況を監査することができる
KSMキー
- KMSキーには「AWSマネージド型」と「カスタマーマネージド型」がある
- AWSによって作成・管理されるものは「AWSマネージド型」であり、ユーザーは削除できない
- AWSマネージド型の鍵は、連携したEBSやRedshiftなどのサービスで暗号化を利用したタイミングでAWSが作成する
- カスタマーマネージド型のKMSキーはユーザーが作成・削除、および管理を行う
- 作成した鍵を長期間利用するのはセキュリティ上危険なため、KMSでは鍵の自動ローテーション(定期的な更新)をサポートしている
キーポリシー
- カスタマーマネージド型のKMSキーへ適用するリソースベースのポリシー
- 鍵に対して、IAMユーザーまたはIAMロール、他のAWSアカウントへの操作可能な権限を設定
- 鍵の作成者とは異なるIAMユーザーやIAMロールが、鍵を使って暗号化や復号をしたい場合、キーユーザーとして使用者を追加できる
- 別のAWSアカウントで鍵を使用したい場合は、対象のアカウントと鍵を共有する(クロスアカウント)
- AWSマネージド型の鍵はキーポリシーを編集できないため他アカウントと共有できない
AWS CloudHSM
- 専用のハードウェアデバイスを用いて暗号化鍵を生成・管理するサービス
- 貸し出されるハードウェアは世界的な暗号化ハードウェアの規格(FIPS 140-2 のレベル 3)で認証済みで、信頼度が高い
- 鍵の生成や保管・削除などのライフサイクル管理はユーザー自身が行う
- 運用面においても、CloudHSMは他のAWSユーザーと分離するためにAmazon VPC内にプロビジョニングする必要があるなど、KMSよりもセキュアな運用が求められる
- 専用のハードウェアを使用する分、KMSと比べると利用料金が高価に設定されている
- AWSクラウド上で暗号化鍵を管理するKMSよりもセキュアな運用が求められるようなケースで利用
AWS Config
- AWSリソースの設定を管理し、記録・評価するサービス
- AWSリソースの設定がいつ変更されたかを記録し、変更がルールに準拠したものでない場合には「非準拠」として記録
SNS通知
- Configでは指定したリソースに設定変更があった場合に、SNSから通知を受け取るように設定できる
- ルールに準拠していないリソースがある場合に通知を受け取る場合は、Amazon EventBridgeと連携する。
- ルールが非準拠になったことをトリガーにしたEventBridgeのイベントルールを作成し、 SNSから通知するよう設定
ルール
- ルールの作成には、AWSが用意したルールをカスタマイズしたり、Lambda関数を使用した独自ルールを追加したりできる
- 例えば、AWSリソースに対して用途や環境などの管理のためにタグを付与している場合、AWS Configの「required-tags」ルールではタグの付与漏れがないかをチェックできる
- 2022年6月現在では、EC2、ELB、RDS、Redshift、S3などのリソースに対応
Amazon Cognito
- モバイルアプリケーションやWebアプリケーション向けのユーザー認証機能を提供するサービス
- 新たにユーザー登録を行ったり、外部のIDプロバイダと連携したユーザー認証、およびユーザーの管理も行える
- ユーザー数の上限がデフォルトで2000万と非常に大きいため、不特定多数のユーザーが利用するアプリケーションのユーザー管理に適している
AWS Trusted Advisor
- 利用者のAWS環境をAWSに蓄積されたベストプラクティスと照会することにより、推奨されるアクションのアドバイスを行うサービス
S3
- S3のサーバー側の暗号化方式(SSE)には3種類ある
- SSE-S3:S3が管理している鍵を使用する
- SSE-KMS:AWS KMS(AWS Key Management Service)に保存されているKMSキーを使用する
- SSE-C:ユーザーが管理している鍵を使用する
AWS Direct Connect
- オンプレミスなどのユーザー環境からAWSへ、専用回線を使ってセキュアに接続するサービス
- インターネット回線ではなく専用回線を敷設して使用するので、安定した高速なネットワークで接続できる
- Direct Connectは、Direct ConnectロケーションのDirect ConnectエンドポイントからAWSネットワークへの接続を保証
- AWSユーザーはDirect Connectロケーション内にルーターを設置し、オンプレミスから専用線を引き込む必要がある
- 工事費用と時間をかけてでも、安定した通信と強固なセキュリティ環境を求めるケースに適している
- Direct Connectにはパブリック接続とプライベート接続がある
- パブリック接続はS3やDynamoDBなどのVPC外にあるAWSリソースへの接続に利用
- プライベート接続はVPCに仮想プライベートゲートウェイ(VGW:Virtual Private Gateway)を配置し、VPC内のAWSリソースへ接続する時に利用
AWS Direct Connectロケーション
- オンプレミスとAWSのデータセンターとを相互に接続するポイントのこと
- 各リージョンに複数用意されており、ユーザーは接続するロケーションを選択できる
- 東京リージョン(ap-northeast-1)では、東京や大阪など5つのロケーションが用意されている
AWS Direct Connectエンドポイント
- Direct Connectエンドポイントとは、Direct Connectサービス提供範囲にあるオンプレミス側の終端のルーターのこと
- Direct Connectロケーション内に物理的に設置されており、AWSユーザーが設置したルーターと接続する
Direct Connectゲートウェイ
- Direct Connectのプライベート接続はDirect Connectエンドポイントと仮想プライベートゲートウェイを1対1で接続するので、通常は1つのVPCにしか接続できない
- Direct Connectエンドポイントから複数のVPCに接続したい場合はDirect Connectゲートウェイを利用する
- Direct ConnectゲートウェイはDirect Connectエンドポイントと仮想プライベートゲートウェイの間に配置されて、世界中の各リージョンにある複数のVPCへ接続できるようになる
- VPCは他のAWSアカウントのものであっても接続可能
- Direct Connectゲートウェイで接続した複数のVPCは、Direct Connectエンドポイントとの通信は可能だが、Direct Connectゲートウェイ経由でVPC同士の通信はできない
- VPC同士の通信を行う場合は、VPCピアリングもしくはAWS Transit Gatewayを利用
Direct Connectの高可用性の実現
- Direct Connectでは、オンプレミスから複数のDirect Connectロケーションへの接続をサポートしている
- 利用しているロケーションの障害に備えて複数のロケーションへ接続することで、可用性を高められるようになっている
AWS DataSync
- オンプレミスとAWS間、またはAWSストレージ間のデータ転送サービス
- 対応するAWSのストレージにはAmazon S3やAmazon EFS、Amazon FSxなど
- オンプレミスとAWS間で通信するためには、オンプレミスにDataSyncエージェントを導入する必要がある
S3
オブジェクトロック関連
リテンションモード
- ガバナンスモード:
- 特別なアクセス許可なしに、ユーザーはオブジェクトのバージョンの上書きや削除、ロック設定を変更することができない
- コンプライアンスモード:
- ルートユーザー含め、ユーザーはオブジェクトのバージョンの上書きや削除ができない
- リテンションモードの変更もできない
- 保持期間の短縮もできない
オブジェクトロックの有効期間
- 期間指定:
- 指定した期間オブジェクトが削除されないようにする
- リーガルホールド:
- 永続的にオブジェクトが削除されないようにする
- オブジェクトを削除する場合は、この設定を削除しなければならない