LoginSignup

This article is a Private article. Only a writer and users who know the URL can access it.
Please change open range to public in publish setting if you want to share this article with other users.

More than 5 years have passed since last update.

@smallpalace(Komiya)

AWSセキュリティのベストプラクティスのホワイトペーパー読んだ

Posted at

セキュリティのベストプラクティスのホワイトペーパー読んだ備忘録です。
https://d1.awsstatic.com/whitepapers/ja_JP/Security/AWS_Security_Best_Practices.pdf
覚えるための写経のようなものかつ独自の解釈が含まれるので元のやつ読んだらいいと思います。

・トラスステッドアドバイザ

一般的なポートがanyで開いてないかとかをみてくれるらしい
https://aws.amazon.com/jp/premiumsupport/trustedadvisor/best-practices/?nc1=h_ls

・IAMまわり

クロスアカウントスイッチは以前やったことあった
https://qiita.com/smallpalace/items/9c228b6a1b6924b0a7cb

IAMロールをインスタンスにくっつけてSTS認証とかはよくやるやつでリソースポリシーを割り当てる感じで
人が使う用にIAMグループに追加するタイプは機能ポリシーというらしい。

・OSの認証

LinuxはSSH鍵つかう

Windowsはec2config サービスによってインスタンス起動時に管理者パスワードが生成され鍵で暗号化される
ので鍵で復号化して取得する

CloudHSMで暗号化、鍵にアクセスする経路をDirectConnectで保護することもできる等
相互SSL接続、アプリでサポートされるCloudHSM用のAPIを使うことができる

・保管時のデータの保護

ケースバイケースで色々書かれており
間違い削除には最小限の適切な権限がベストである等々

S3
バックアップ（バージョニングとレプリケーションがそのかわりだけどオンプレにバックアップもどうぞと書かれている
バージョニング（デフォルト無効だけど有効化しとくと過去バージョンを復旧可能に）
レプリケーション（それぞれのリージョンのすべてのAZにレプリケーションされてるがオペミスの復旧はできない）
サーバ側での暗号化（AES-256 でAWSで生成されたマスターキーが定期的にローテーションされる
クライアントの暗号化（お客様独自暗号化キー作成し管理、送信前に暗号化し受信後に復号化する
任意の暗号化アルゴリズム・対象・非対称キーをいずれも使用可能でAWS提供のJavaSDKにはクライアント暗号化機能入り

EBS
レプリケーション（されるが同AZ内にある
バックアップ（スナップショットをとってね、IAMロールで機能わりあててね
暗号化（WinはEFSとBitlockeerつかえるがBitlockerはデバイスのやつは無理）
　Linuxはdm-cryptとかつかえるキー管理はLUKSとか色々な暗号がつかえる
　TrueCryptはWinもLinuxもいける
　暗号化と整合性認証：SafeNetProtectV　ボリューム全体の暗号化とAMIのプリブート認証する

RDS
認証がいる場合はアプリケーションレイヤで保護することもでき、
SQLの暗号化関するでプラットフォームレイヤで保護もできる
アプリレイヤ
　機密性の高いデータベースフィールドをすべて暗号化する組み込みの暗号化関数を使用する
　データベースに保存する前にアプリケーションキーを使用する
　PKIによるる対称暗号化や、マスター暗号化キーを提供するその他の非対称キーによる手法を使用して
キーを管理

　　MySQL
　　　　AES_ENCRYPT関数（https://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html)
　　Oracle Transparent Data Encryption はAmazon RDS for Oracle EnterpriseEdition の、
　　　自分のライセンス使用 (BYOL) モデルでサポート
　　Microsoft SQL
　　　Microsoft Transact-SQL のデータ保護機能には、暗号化、署名、ハッシュが含まれる
　　　（http://msdn.microsoft.com/en-us/library/ms173744）

SQL の範囲のクエリは、データの暗号化された部分には適用されないことに注意（つまりlikeでワイルドカード検索できない）
日付だけ暗号化しない等で暗号化してないフィールドで範囲検索をすることは可能

Glacier（グレイシア）
AES256のキーでサーバ側で保管時に暗号化されキー自体はマスタキーで暗号化される
マスタキーは定期ローテされる。強化したいなら暗号化してからアップロードも可能

DynamoDB
標準 DynamoDB サービスに加えてデータ暗号化レイヤーを実装することもできる
範囲検索はやっぱりできない
DynamoDB は数値、文字列、raw バイナリデータ型のフォーマットをサポー
トする。DynamoDB に暗号化されたフィールドを保存する場合のベストプ
ラクティスは、raw バイナリフィールドまたは Base64 でエンコードされた文
字列フィールドを使用すること

EMR（のデータの保護）
マネージドインスタンスでカスタマイズはできないサービスでありデフォで暗号化されない。
永続データストアとしてS3かDynamoをつかうことが多い。
-S3サーバ側暗号化データストアからHDFSにコピーしないで処理、S3クライアント側の暗号化、
復号化はカスタムシリアライザー・デシリアライザーをHiveやMapReduceジョブ用のImputFormatとともにつかう
ファイルを分割するには行またはレコード事に暗号化適用する
-アプリケーションレベルの暗号化、ファイル全体の暗号化、保存する際にHMAC-SHA1などで暗号化と保護をする
復号化にはカスタムSerDeとHiveかスクリプトやブートストラップアクションでS3からデータをフェッチして復号しHDFSにロードしてから処理
全体が暗号化されているのでマスター等単一ノードでの処理となる。S3Distcp など特殊なコーデックとともにつかう
-アプリケーションレベルの暗号化、個々のフィールドの暗号化・構造の維持
Hadoopでは標準SerDeつかう、復号はHadoopジョブのMapステージ中に実行でき、ストリーミングジョブ
用のカスタム復号ツールによって標準入力/出力のリダイレクトを使用できる。

・データとメディアの安全な廃棄

クラウドと従来のオンプレ環境では廃棄方法が違い、データ削除依頼でメディアまでは廃棄されることはない。
ハイパーバイザかVMマネージャがインスタンスの書き込み先のブロックを追跡する
国防省の「国家産業セキュリティプログラム運営マニュアル」か「媒体のサニタイズに関するガイドライン」
に詳述された技術で廃棄プロセスの一環としてデータを廃棄する
詳細はセキュリティプロセスのホワイトペーパーをみるとよい模様。

・伝送中のデータの保護

  • ウェブアプリ：HTTPSで証明書認証とともに保護
  • HTTPSのオフロード：マシンリソースがかかるのでELBをつかってね（クライアント認証はできない）
  • RDPリモートデスクトップ：デフォでSSLだけど証明書はなりすまし防止に自己署名じゃなくて信頼されたX509証明書をつかおう
  • SSH：トンネリングもできるよ、非特権ユーザでSSHバージョン2をつかおう
  • データベース：製品についてるSSL機能があるはず Dynamo AWS内はいいがインターネット越しはSSL/TLSで通信しましょう EMR 通信パスそれぞれで個別に気にするひつようがある Hadoopノード間：同じ拠点にあるので通常は追加保護は不要 HadoopクラスタとS3/DynamoDB間：デフォはhttpsが使用される Hadoopクラスタとユーザ/アプリ間：トンネリングはSSH/RestはSSL、TLS Hadoopクラスタ管理アクセス：マスタノードへSSH

・OSとアプリのセキュリティ保護

推奨事項
- ルート API アクセスキーとシークレットキーを無効にする
- セキュリティグループを使用して、制限された IP 範囲からのインスタン
スへのアクセスを制限する
- ユーザーマシンの .pem ファイルをパスワードで保護
- 誰かが退職したり、アクセスの必要がなくなった場合に、インスタンス
上の承認されたキーファイルからのキーを削除する
- 認証情報 (DB、アクセスキー) を更新する
- IAM ユーザーのアクセスアドバイザー、または、IAM ユーザーが前回使
用したアクセスキーを使用して、最小特権チェックを定期的に実行する
- 拠点ホストを使用して、制御と可視性を強化する

・カスタムAMIの作成

AMIの発行者は初期のセキュリティの責任を負う
推奨されるタスク
- 安全でないアプリケーションの無効化
- 公開範囲の最小化
- 認証情報の保護(すべての認証情報や証明書を削除など
- 良好なガバナンスの使用（AWSの規約、例えばSMTP オープンリレーやプロキシサーバーは禁止などに反しないこと）

・ブートストラッピング

インスタンス化後もブートストラップアプリケーションを用いてセキュリティコントロールを修正・更新できる
一般的なブートストラップアプリ：
- Puppet, Chef, Capistrano, Cloud-Init, Cfn-Initなど
サードパーティツールではなくブートストラップ用カスタムBashスクリプトまたはPowerShellスクリプト実行も可能
一般的なブートストラップアクション例：
- セキュリティ更新プログラムで最新パッチ・サービスパックなどをインストール
- コンテキスト依存データと設定により起動環境に固有の設定をインスタンスに適用
- リモート管理システムにインスタンスを登録

・パッチの管理

AMIとライブインスタンスのパッチ管理は実施責任が使用者。制度と手続きの文書化整備推奨。
OSとアプリのパッチをインストールされてるものと最新の弁だセキュリティパッチとを比較確認推奨。
脆弱性リスク特定してランク付け運用をする。

・パブリックAMIのセキュリティ管理

パブリックに提供する場合はAMIに重要な認証情報を残さないように注意。
https://aws.amazon.com/jp/articles/how-to-share-and-use-public-amis-in-a-secure-manner/

・マルウェアからのシステムの保護

ウィルス、ワーム、トロイの木馬、ルートキット、ボットネット、スパムなどの脅威からクラウドのシステムも保護する。
ざっくりは信頼できないものを使わないと書かれていた
- AMI：信頼できるものをつかう、標準からカスタムする場合はその内容すべてが信頼できる必要がある
- ソフトウェア：信頼できる業者（業界で評判が良く、責任を持てる安全な方法でソフトウェアを開発しており、悪意のあるコードがソフトウェアパッケージに混入することを許さない、多くの場合、コード署名用の証明書を使ってソフトウェアに署名するか、製品の MD5 または SHA-1 署名を提示して、ダウンロードしたソフトウェアの健全性を確認できるようにしている）
- ソフトウェアリポジトリ：ユーザーが信頼できるソフトウェアをインストールして利用できるように、独自の内部ソフトウェアリポジトリをセットアップすることをお勧め、様々な場所からというのは危険なのでしないように
- ユーザ権限：最小限の原則をまもることで被害を軽減
- パッチ適用：最新のセキュリティパッチを適用する
- ボットネットを防ぐ：ここまでの対策をすべて実施
- スパム対策：SMTPオープンリレーを禁ずる
- 利用規定：　https://aws.amazon.com/jp/aup/
- ウィルス対策：システムで評判の良い最新のウィルスおよびスパム対策ソリューションを必ず利用
- 侵入・改ざん検知：OSSEC のような、ファイル整
合性チェック機能やルートキット検出ソフトウェアを含む、ホスト方式の IDSソフトウェアをインストール・検知する
- ウィルスにかかったら：システムデータをすべて保存し、システム、プラットフォーム、アプリケーションの実行可能ファイルをすべて信頼できるソースから再インストールして、データはバックアップからのみ復元する

・侵害と迷惑行為の軽減

AWSが用いてるメカニズムは、
内部イベント監視、NW空間に対し外部セキュリティインテリジェンス、リソースに対するインターネット迷惑行為関連の苦情など

意図しない迷惑行為の例は、
- 侵害されたリソース、ウィルス感染したボットネットインスタンス
- 意図しない迷惑行為、顧客がS3にマルウェアを置く
- 間違った苦情、インタネットユーザの誤解によるもの

  • AWSから迷惑行為の警告をうけたら,直ちに調査してください、対応できない場合はアカウント停止して安全を守ることに。
  • セキュリティのベストプラクティスに従う、最新のソフトウェアパッチの適用、ファイアウォールまたは Amazon EC2 セキュリティグループによるネットワークトラフィックの制限、ユーザーに対する最小限のアクセス権限の付与など、シンプルな防御慣行を一貫して採用してください。
  • 侵害の軽減、対策としてはシャットダウン、原因調査はSSH単独アドレスからのポート以外すべてを遮断して調査、またはEBSのスナップショットをとり調査にまわすなど、訓練された専門家が調査する、ゲストOSレベルの調査をするのは自前でログとるなど自己責任。 復元手順として感染インスタンスの消去、バックアップから復元、セキュリティ管理の見直しなど。
  • セキュリティ用の連絡Eメール設定をするPersonalInformation>ConfigureAdditionalContact

・ その他のアプリケーションセキュリティ慣行の採用

いくつかのベストプラクティス
- AMI作成時、パスワードやSNMPコミュニティ名などのデフォルト値を必ず変更する
- 不要なユーザアカウントを削除・無効化
- 異なるセキュリティレベルのロールをインスタンスに複数持たせないようにする（WEBとDBを分けるなど）
- 必要とするサービス、プロトコル、デーモンのみを有効にして他は止める。
- スクリプト、ドライバ、フィーチャー、サブシステム、EBS ボリュームなどの不要な機能と不要なウェブサーバーはすべて無効か削除する

そのほかtelnetじゃなくてSSH、ユーザおよびサイト間IPSecVPN、暗号化、SSL・TLSをつかおうなど

・Amazon Virtual Private Cloud (VPC) の使用

VPCはパブリッククラウド内にプライベートクラウドつくれる的なの
VPCへのリソースアクセスは4種類で
- インターネットのみ（SSLやSSHで接続
- インターネットとIPSecでトンネリング（VPNでVGWとCGWとVPN接続でIPSec確立
- DirectConnectでIPSecなし（要件次第で追加の保護なしOK
- DirectConnect+IPSec(インターネットの場合と同じ

IPSecかDirectConnectどちらかで透過的アクセスが統合できる（つまりプライベートIPでの接続が可能に）
細かい話はAmazon VPC 接続オプションのホワイトペーパーをみてねと。（英語しかみつからなかったけどブラウザ翻訳はできてた）
https://docs.aws.amazon.com/ja_jp/aws-technical-content/latest/aws-vpc-connectivity-options/introduction.html

・セキュリティゾーニングとネットワークセグメンテーションの使用

以下のアクセスコントロールリストを使ってセグメントを構築可能
- VPC：ワークロードか組織エンティティごとに、分離したネットワークを定義
- SecurityGroup: 機能とセキュリティ要件が類似したイ
ンスタンスに対するアクセスを管理(、許可され確立されたあらゆる TCP セッションまたは UDP 通信チャネルで、双方向のファイアウォールルールを有効にするステートフルファイアウォール)
- ネットワークアクセスコントロールリスト (NACL) :IP トラフィックのステートレス管理(トラフィックがセキュリティグループに到達前に制御可能
- ホストベースのファイアウォール: インスタンスにアクセス制御
- 脅威保護レイヤー：トラフィックフローに作成しゾーンを通るようにする
- 他のレイヤーにアクセスコントロール: を適用（例えばアプリケーションレイヤやサービスレイヤ

セキュリティゾーンを作成するには、ネットワークセグメントごとに追加のコントロールが必要であり、多くの場合、以下のようなコントロールを含む

  • 共有アクセスコントロール：中央集権のIDアクセスマネジメントシステム（フェデレーションもできるがIAMから分離することが多い（たぶんLDAPとかのこと
  • 共有監査ログ記録：イベント分析と相関、およびセキ ュリティイベントの追跡に必要（CloudwatchLogsとかfluentdとかAuditLogsとかCloudTrailとかかな
  • 共有データ分類：詳しくは、「表 1: 資産のマトリックスのサンプル」資産を保護するための ISMS の設計セクションを参照
  • 共有管理インフラストラクチャ：ウィルス・スパム対策システム、パッチ適用システム、パフォーマンスモニタリングなどの多様なコンポーネント
  • 共有セキュリティ（気密性・整合性）要件：– 多くの場合、データ分類と組み合わせて検討される

ネットワークセグメンテーションとセキュリティゾーニングの要件を評価する質問

  • ゾーン間通信を制御しますか ?
  • 業務要件に応じて IDS/IPS/DLP/SIEM/NBAD システムを使って、ゾーン間通信をモニタリングできますか ?
  • ゾーンごとにアクセスコントロール権限を適用できますか ?
  • 専用の管理チャネル/ロールを使用して各ゾーンを管理できますか ?
  • ゾーンごとに機密性ルールと整合性ルールを適用できますか ?

柔軟なセキュリティーゾーニングオプション
- サブネット単位のアクセスコントロール
- セキュリティグループ単位のアクセスコントロール
- インスタンス単位のアクセスコントロール (ホストベース)
- Amazon VPC 単位のルーティングブロック
- リソース単位のポリシー (S3/SNS/SMS)
- ゾーン単位の IAM ポリシー
- ゾーン単位のログ管理
- ゾーン単位の IAM ユーザー、管理ユーザー
- ゾーン単位のログフィード
- ゾーン単位の管理チャネル (ロール、インターフェイス、マネジメントコ
ンソール)
- ゾーン単位の AMI
- ゾーン単位のデータストレージリソース (Amazon S3 バケットまたは
Glacier アーカイブ)
- ゾーン単位のユーザーディレクトリ
- ゾーン単位のアプリケーション/アプリケーションコントロール

・ネットワークセキュリティの強化

ユーザ認証とアクセス制限だけだと不十分なのでベストプラクティスに従いましょうと。
- 常にセキュリティグループを用いる(インスタンスレベルのファイアウォール、1つのインスタンスに複数当てられる（けど複数当てるのはパフォーマンスがアレだと中の人に言われたことはあるな））
- ネットワーク ACL を使ってセキュリティグループを強化する、ステートレスだが高速でインスタンス特融でないのでコントロールレイヤを増やせる。ACL 管理とセキュリティグループ管理には職掌分散を適用可能。
- ほかのサイトへの信頼できる接続のためにIPSec または AWS DirectConnect を使用する。
- データの機密性と整合性、通信者身元保証のために伝送中のデータを保護する
- 大規模デプロイの場合、ネットワークセキュリティをレイヤーに分けて設計。ネットワークセキュリティを保護する単一のレイヤーを作成する代わりに、外部、DMZ、内部の各レイヤーにセキュリティネットワークを適用
- VPC フローログでは、VPC のネットワークインターフェイス間を行き来する IP トラフィックに関する情報をキャプチャできるようになるため、さらに可視性が向上する

サービスエンドポイント監視可能。IAM ポリシーを使用すると、リクエストの送信元 IP アドレスに基づいて、リソースへのアクセスを制限することが可能。

・周辺システムの保護: ユーザーリポジトリ、DNS、NTP

カスタム内部DNSをEC2に構成する場合の管理
- 管理レベルアクセスの分離
- モニタリング、アラート、監査証跡
- ネットワークアクセスレイヤコントロール
- セキュリティパッチが適用された最新の安定したソフトウェア
- 継続的なセキュリティテスト
- ほかのあらゆるセキュリティ管理プロセスの導入（ISMS)

DNS以外に
アクセスコントロールシステム、IAMはAWS向けだがOSとアプリ向けの認証システム（ Active Directory や LDAP、RADIUS のようなエンドユーザーリポジトリ）は自前でどうにかする必要がありこれもセキュリティ上重要で注意が必要

時刻サーバも重要なカスタムサービス。ログのタイムスタンプや証明書の検証など、多くのセキュリティ関連トランザクションに欠かすことができない。

PCIDSSの時刻同期に関する優れたスタンダード。
- 時刻同期技術が実装され最新状態であることを確認
- 正しい時刻を組織内で入手、配布、保管するプロセスを見直し、システムコンポーネントのサンプルについて時刻関連のシステムパラメータ設定を確認
- 指定された中央時刻サーバーのみが外部ソースから時刻信号を受け取り、外部ソースからの時刻信号は国際原子時または協定世界時 (UTC) に基づいていることを確認
- 指定された中央時刻サーバーがピア通信しほかはそこから同期
- 必要なユーザのみに制限
- システム設定と時刻同期設定およびプロセスをレビューして、重要なシステムの時刻設定への変更がログ記録、モニタリング、およびレビューされていることを確認
- 業界が認定している特定の外部ソースからの時刻の更新をタイムサーバーに適用できることを確認する。(これにより、悪意のある個人がクロックを変更することを防止できます)。(対称キーで暗号化された更新を受け取るように設定することも、更新されるクライアントマシンの IP アドレスを指定するアクセスコントロールリストを作成することもできます。
これにより、内部タイムサーバーの不正使用が防止されます)。

・脅威保護レイヤーの構築

多層セキュリティがネットワークインフラストラクチャを保護するためのベストプラクティス。
クラウドでは、VPC、ハイパーバイザーレイヤーにおける暗黙的ファイアウォールルール、ネットワークアクセスコントロールリスト、セキュリティグループ、ホストベースのファイアウォール、および IDS/IPS システムを組み合わせて、ネットワークセキュリティを確保するための階層型ソリューションを構築する。

セキュリティグループ、NACL、およびホストベースのファイアウォールで足らない場合はネットワークレベルのセキュリティコントロールアプライアンスをデプロイする必要がある。
これはインラインで行う必要があり、これによりトラフィックがアプリケーションサーバーなどの最終送信先に転送される前に遮断され、分析される。

インライン脅威保護テクノロジーの例としては以下のようなものがある。
- Amazon EC2 インスタンスにインストールされたサードパーティーのファイアウォールデバイス (別名ソフトブレード)(WAF:ウェブアプリケーションファイアウォールのことかな）
- 統合脅威管理 (UTM) ゲートウェイ(ワンセットのやつ(https://www.hs-juniperproducts.jp/check/utm.html) )
- 侵入防止システム(IPS(https://www.infraexpert.com/study/security3.html) )
- データ損失管理ゲートウェイ(DLP(https://it-trend.jp/words/dlp) )
- 異常検出ゲートウェイ（https://it-trend.jp/ids-ips/article/explain#chapter-8)
- 持続的標的型攻撃検出ゲートウェイ(産業スパイぽいやつ：https://www.trendmicro.com/vinfo/jp/threat-encyclopedia/web-attack/95/understanding-highly-targeted-attacks)

Amazon VPC インフラストラクチャの以下の主要な機能が脅威保護レイヤーテクノロジーのデプロイをサポートしている

  • 多重ロードバランサーレイヤーのサポート
    例えば、User->DNS->ELB->WAF->内部ELB->APPというかんじ

  • 複数の IP アドレスのサポート
    たとえば保護すべきサービス種別毎にIPをつかい単一のインタフェースに複数IPがつけられること

  • 複数の Elastic Network Interface (ENI) のサポート
    多くの場合冗長性を必要とするのでその機能のためにとマルチゾーンでデプロイなど。

  • 分散型脅威保護ソリューション
    エージェント型で収集した情報を中央脅威管理サーバであつかう

  • オーバーレイネットワーク脅威保護ソリューション
    GRE トンネルやvtun インターフェイスなどのテクノロジーを使用する Amazon VPC を基盤として、または一元管理されているネットワークトラフィック分析と侵入検知システムに別の ENI のトラフィックを転送して、オーバーレイネットワークを構築する。これにより、アクティブまたはパッシブな脅威応答が可能になる

・セキュリティのテスト

すべての ISMS では、セキュリティコントロールとポリシーの有効性を定期的にレビューする必要がある

テストアプローチ
外部は構成を知らない第三者が、内部は知っているものによるテスト。

  • 外部脆弱性評価
  • 外部侵入テスト
  • アプリケーションとプラットフォームの内部グレー/ホワイトボックスレビュー

AWSで侵入テストを実施するにはアクセス権限をリクエストする必要がある。
詳細については、「アマゾンウェブ サービスの適正利用規約 – (http://aws.amazon.com/aup/) 」を参照する
マネコンにログインして申請フォーム書いて出す
フォームには、テストするインスタンスに関する情報や予想されるテストの開始日時と終了日時を入力し、侵入テストおよびテストに適切なツールの使用に関する諸条件に同意する必要がありm1.small または
t1.micro のテストは許可されていない。
フォームを提出すると、リクエストの受領を確認する通知が 1 営業日以内に送信される

・メトリクスの管理と向上

ISMSではコントロールの有効性の測定が不可欠

測定と向上のためのベストプラクティス
- 手順とその他のコントロールのモニタリングおよびレビュー
- ISMSの有効性の定期的なレビュー
- コントロールの有効性の測定
- 定期的なリスク評価レビュー
- 内部ISMS監査
- 定期的な管理レビュー
- セキュリティ計画の更新

・DoS & DDoS攻撃の緩和と保護

リスクプロファイルは、ビジネスの性質、最新のイベント、政治情勢、テクノロジーの公開によって異なり
緩和および保護の技術は、オンプレミスで使用されているものと似ている
DDoS対策に懸念があるならプレミアムサポートを強く推奨、攻撃の緩和または進行中のインシデントを阻止するプロセスでサポートから事前または事後サービス提供可能

S3は抽象化サービスだから複数アカウントからのアクセスOKで自ら追加の保護は不要だがベストプラクティスに従ってねとのこと

EC2はOSや顧客データの管理などは自前。
トラフィックがDDoSであるかはユーザが判断
通常時の倍のアクセスならCloudWatchとSNSでアラームをトリガされるようにしておくなど

DoS/DDoS 攻撃の緩和と保護のための一般的なア
プローチ

  • ファイアウォール:セキュリティグループ、ネットワークアクセスコントロールリスト、ホストベースのファイアウォール
  • ウェブアプリケーションファイアウォール (WAF)
  • ホストベースまたはインラインのIDS/IPS システム -トラフィック形成/レート制限
  • 未発達セッション制限（TCP SYNフラッディング制限）

DDoS対策の異なるアプローチとしてELB、AutoScalingは伸縮自在でスケールするので既存顧客を地理単位で丸ごと拒否することなく使えるという攻撃を吸収するものがあり、その場合コストがかかるが攻撃のリソースもかかる（ので諦めさせやすい
CloudFrontでDoS/DDoS フラッディング攻撃を吸収することができAWS WAFと統合されていてウェブアプリケーションを保護するのに役立つ。エッジで吸収されるのでバックエンドサーバへの影響が少ないかゼロに。コストは生じるが攻撃者側のコストもあるので金額に見合う効果がある
DoS/DDoS 攻撃に対する露出を効果的に緩和、阻止、管理するには、このドキュメント全体で言及されているレイヤー防御モデルを構築する必要がある

・セキュリティモニタリング、アラート、監査証跡、インシデント対応の管理

オンプレで使ってるものはそのまま使える

ENISAにまとめられてるクラウド契約におけるセキュリティサービスレベルの監視ガイド
https://www.enisa.europa.eu/publications/procure-secure-a-guide-to-monitoring-of-security-service-levels-in-cloud-contracts

セキュリティモニタリングを開始する前の確認事項

  • 測定するパラメータ
  • これらを測定する方法
  • これらのパラメータのしきい値
  • エスカレーションプロセス
  • データを保存する場所

多くの場合、最も重要なのは、ログ記録を行うには何が必要であるかを確認
すること。ログ記録と分析を行うには、以下を設定することを推奨。

  • ルートまたは管理者権限のあるユーザーが実行するアクション
  • すべての監査証跡へのアクセス
  • 無効な論理的アクセスの試み
  • 識別と認証のメカニズムの使用
  • 監査ログの初期化
  • システムレベルのオブジェクトの作成と削除

ログファイルに関する考慮事項

  • ログ収集（方法）
  • ログトランスポート(安全に転送）
  • ログストレージ （一元管理してリテンションポリシーと分析を容易に）
  • ログ分類
  • ログ分析/相関 　ログファイルを分析してログファイル内のイベントを相互に関連付けることで、セキュリティインテリジェンスが得られる
  • ログの保護/セキュリティ　ログファイルには機密情報が含まれる。ネットワークコントロール、IAM、暗号化、データ整合性の認証、および改ざ んが不可能なタイムスタンプでログファイルを保護する

ファイアウォール、IDP、DLP、AV システム、オペレーティングシステム、プラットフォーム、アプリケーションなどのさまざまなネットワークコンポーネントがログファイルを生成しその多くがセキュリティに関連しており、ログファイル戦略に組み込まれる必要がある。
ログにはユーザーのアクティビティ、例外、セキュリティイベントが含まれている必要があり、ログは将来の調査で使用できるように特定の期間にわたって保存しておく必要がある

どのログファイルを含めるかを判断するには、以下の点を考慮する

  • クラウドシステムのユーザー。どのように登録するか、どのように認証するか、リソースにアクセスする権限をどのように受けるか
  • クラウドシステムにアクセスするアプリケーション。どのように認証情報を取得するか、どのように認証するか、そのようなアクセスのための 権限をどのように受けるか。
  • AWS インフラストラクチャ、オペレーティングシステム、アプリケーションへの特権アクセス (管理者レベルのアクセス) を持っているユーザ ー。どのように認証するか、そのようなアクセスのための権限をどのように受けるか。

多くのサービスににアクセスコントロール監査証跡が組み込まれているが（S3やEMR）ログ記録のビジネス要件が一般的にとれるより厳しい場合特権エスカレーションゲートウェイを使用してアクセスコントロールログと認証を管理することを検討する

特権エスカレーションゲートウェイで検索するとAmazonInspectorが出てくるがここで言われてるものとは違いそう
https://qiita.com/s5601026/items/91ab636c9867b76c2414

特権エスカレーションゲートウェイを使用する場合、システムへのすべてのアクセスを単一の (クラスター化された) ゲートウェイで一元管理する。AWS イ
ンフラストラクチャ、オペレーティングシステム、またはアプリケーションを直接呼び出す代わりに、インフラストラクチャへの信頼済みの中間証明書として機能するプロキシシステムによってすべてのリクエストが処理される。このようなシステムは以下のような処理をする。

  • 特権アクセスのための自動パスワード管理（Active Directory、UNIX、LDAPなど、組み込みコネクタでポリシーに基づいたパスワードと認証情報のローテーションを自動的に行う
  • IAM ユーザーのアクセスアドバイザーと AWS IAM ユーザーが前回使用したアクセスキーを使用して最小権限チェックを定期的に実行
  • フロントエンドにおけるユーザー認証とバックエンドにおける AWS のサービスへの委任アクセス（シングルサインオンで認証プロファイルに基づいてアクセス権限があてられフロントwebはトークンベースでそのほかへはクリックスルーが一般的アプローチ
  • すべての重要なアクティビティの改ざんが不可能な監査証跡
  • 共有アカウントの複数のサインオン認証情報
  • ターゲットシステムへのアクセスのみを許可することによるリープフロッギングまたはリモートデスクトップホッピングの制限
  • セッション中に使用できるコマンドの管理 -コンプライアンスおよびセキュリティ確保のためのターミナル用監査証跡および GUI ベースセッションの提供
  • ポリシーの特定のしきい値に基づくすべてのログ記録とアラート

・変更管理ログの使用

セキュリティログを管理することで、変更を追跡もできる。
変更はシステムのインフラストラクチャ側で発生する場合もあれば、コードリポジトリの変更、ゴールドイメージ/アプリケーションインベントリの変更、プロセスとポリシーの変更、ドキュメントの変更などの他のカテゴリに関連するものである場合もある。
上記のすべてのカテゴリの変更に、不正操作が不可能なログリポジトリを使用することを推奨。
ログを管理する特権は標準ユーザにもたせてはいけない。1日一回は（IDSやAAAサーバなどのシステムによって）レビューが必要。
たぶんAWSに関してはCloudTrailと思われる。

・重要なトランザクションログの管理

重要なアプリケーションの各ログエントリに必要な情報
- ユーザー識別情報
- イベントのタイプ
- 日付とタイムスタンプ
- 成否
- イベントの原因
- 影響を受けたデータ、システムコンポーネント、またはリソースの ID または名前

・ログ情報の保護

ログ記録設備とログ情報は改ざんおよび不正アクセスから保護されている必要がある
管理者ログと運営者ログはアクティビティの追跡情報を消去する攻撃の標的になりがち

ログ情報を保護するために行われている一般的なコントロールには以下のようなのものがある。

  • 監査証跡がシステムコンポーネントで有効になっており、アクティブであることを確認
  • 職務上の必要性が認められる個人のみが監査証跡ファイルを閲覧できることを確認
  • アクセスコントロールメカニズム、物理的な分離、またはネットワークの分離によって現在の監査証跡ファイルが不正な変更から保護されてい る
  • 変更が困難な一元管理ログサーバーまたはメディアに現在の監査証跡ファイルが迅速にバックアップされていることを確認する
  • 一元管理されている安全な内部ログサーバーまたはメディアに外部向けのテクノロジー (ワイヤレス、ファイアウォール、DNS、メールなど) の ログがオフロードまたはコピーされていることを確認する
  • システム設定、モニタリングされているファイル、モニタリングアクティビティの結果を検証することによって、ログに対してファイル整合性 モニタリングまたは変更検出ソフトウェアを使用する
  • セキュリティポリシーおよび手順を取得し、検証することによって、少なくとも 1 日に 1 回はセキュリティログをレビューする手順がそれらに含 まれており、例外のフォローアップが必要であることを確認する
  • 定期的なログレビューがすべてのシステムコンポーネントで実行されていることを確認する
  • セキュリティポリシーおよび手順に監査ログリテンションポリシーが含まれており、ビジネス要件とコンプライアンス要件によって定義された 所定の期間にわたる監査ログリテンションが必要であることを確認する

・障害のログ記録

イベントのモニタリングに加えて、ソフトウェアまたはコンポーネントの障害をモニタリングする。
障害はハード・ソフト障害や可用性に絡む場合セキュリティインシデントとは無関係である場合も。
サービス障害は、サービス妨害攻撃などの悪意のある意図的なアクティビティの結果である可能性もある。
どの場合でも、障害によってアラートが生成されるため、イベント分析および相互関連手法を使用して、なぜ障害が発生したか、それによってセキュリティ対応がトリガーされる必要があるかどうかを判断する必要がある。

・まとめ

AWS では
　柔軟性、伸縮性、ユーティリティの請求、市場投入までの時間の短縮など、重要な利点を最先端企業に提供
　インフラストラクチャまたはプラットフォームサービスにおいて優れたサービス管理レイヤーを提供する
　広範なセキュリティサービスと機能を利用して資産とデータのセキュリティを管理できる
企業では
　クラウド内のデータの機密性、整合性、可用性を保護し、企業固有の情報保護のためのビジネス要件を満たす責任がある

従来のセキュリティとコンプライアンスの概念はクラウドでも適用される
このホワイトペーパーで説明したさまざまなベストプラクティスを使用して、
独自のセキュリティポリシーおよびプロセスを構築して迅速かつ安全なデプロイを実現推奨

0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin