読者です 読者をやめる 読者になる 読者になる

Day.2 Security IN the AWS Cloud


※このセッション内でのツイートが翌日 Fireside chat の開演前にデカデカと表示されていたそうです。


2日目のセッションはセキュリティ関連を中心に受けてみました。このうち、Security IN the AWS Cloud が実践的な内容だったので復習のため記載しておきます。※なお内容の正確性については保証しませんのであしからず。

このセッションでは、CSISのセキュリティガイダンスにおける20の Critical Security Control(クリティカルセキュリティ管理)の各項目について、AWSでどう実装すればよいかが説明されました。セキュリティガイダンスは以下で読めます。


先にまとめ

  1. 自動化せよ(AWS CloudFormation etc...)
  2. 適切な権限制御をせよ(VPC の NACL、各種 Security Group、IAM、IAM Role on EC2 instances)
  3. ホスト型IDSなどのツールを導入せよ


20 Critical Security Controls Version 4.0 に沿って AWS で実装を行うセキュリティリファレンス
※ところどころ補足説明入れてあります

CC1: 信頼済みとそうでないデバイスの目録

  • 権限制御に IAM を使おう
  • 情報漏洩リスクを最小化するために IAM roles for EC2 instances(IAM role が適用された EC2 インスタンス)を使おう
  • 信頼済みサーバーのリストを ec2-describe-instances コマンドで取得しよう
  • CloudFormation で、あらかじめ定義されたシステム構成と、あらかじめ用意された AMI をデプロイしよう
  • 準備が整うまで、解放するポートは最小限にしよう
  • タグを活用すると簡単にシステム所有者や目的が把握しやすい

CC2: 信頼済みとそうでないソフトウェアの目録

  • 承認済みの AMI
  • Puppet/chef(構成管理の自動化)
  • 承認済みの設定で全てのスタックをローンチするために AWS CloudFormation を使おう
  • ファイルシステムの整合性チェック(侵入検知やrootkit検知)を行う以下のような IDS ツールを使おう
    • OSSEC
    • tripwire

CC3: セキュアなサーバーのハードウェアやソフトウェア

  • 承認済みの AMI
    • 信頼できる提供元から取得しよう
    • マシンイメージは(一度作っておけば)不変だよ
    • 自身のアカウント用にだけカスタマイズして非公開にしておこう
  • CloudFormation/Puppet/chef(構成管理の自動化)
  • 信頼できるソースやリポジトリから取得しよう
  • ホストベース IDS を使おう
  • Security Groups で外部からの攻撃を低減しよう
  • ネットワークACL(アクセス制御リスト)がステートレスフィルター(パケットの通過可否を判定)を提供するよ

CC4: 継続的な脆弱性の評価と修復

  • 裁量によるオンホストテストをしよう
  • ネットワークベースのテストが必要です
  • パッチあてを忘れずに!
    • ほぼ全ての既存のパッチ管理ツールが動作可能です
    • 共通のリポジトリはすでに AWS にもあります
    • 自身のリポジトリの配備も可能です

CC5: マルウェア対策

  • ホストベースのツールやテクニックを使おう
    • たくさんの最新製品があります
  • 追加の防御のために NAT インスタンスで強化しましょう
  • VPC の中の防御フィルタを強化するために NACL を使いましょう
  • 管理上のアクセス権を最小化するために要塞化したインスタンスを使いましょう

CC6: アプリケーションソフトのセキュリティ

  • 最小の接続設定にしてテスト用にアプリケーションをデプロイしましょう
    • Security Groups を使いましょう
    • VPC のプライベートサブネットにテストアプリを置きましょう
  • Roles for EC2 を使いましょう
  • SNS からの警告が、正しい人/システムに通知されるようにしましょう
  • できればプライベート(サブネットの)VPC にデプロイしましょう

CC7: ワイヤレス

  • 特になし

CC8: データリカバリ能力

  • ステートレスなサーバー(S3ベースのように、使うときだけローンチして、使い終わったらターミネートするサーバー)向け
    • AMIs/CloudFormation/Puppet/chef を使って再ローンチ
  • ステートフルなサーバー(常時起動・運用を伴うサーバー)向け
    • EBSベースのインスタンス(現在の主流)を使って、定期的な EBS スナップショットを取ってみましょう
    • データ領域の EBS はより頻繁にスナップショットを取りましょう
  • スナップショット管理を自動化するために定期的にスクリプトを稼働させることを検討しましょう
  • 注釈
    • EBS スナップショットは Amazon S3 に保存されます
  • 大事なデータの保管やレプリケーションには Amazon S3 を使いましょう
  • バケットをセキュアに設定することを忘れないでください
    • Roles for EC2 を使ってアクセスしましょう
    • バージョン管理を検討しましょう
    • ワームっぽい挙動を安全に削除しましょう
  • Amazon Glacier と Amazon S3 を長期保存ストレージに利用することを検討しましょう
  • 注釈
    • Amazon S3 と Amazon Glacier はイレブン9の耐久性です
  • 挙動のあやしいインスタンスを見つけたときに実行するスクリプトを検討しましょう
    • EBS ボリュームの状態のスナップショットを取得する頻度を上げましょう
    • システムの他の部分とのアクセスを分離しましょう
    • 可能な場合はシステム全体でアクセス技術の実装量を軽減しましょう
      • VPC で明示的に拒否するサブネットの NACL を追加しましょう
      • ホストのファイヤーウォールに IP アドレスブロックを追加します
    • Roles for EC2 は credentials が汚染された場合の影響を最小限にできます

CC9: セキュリティスキルのアセスメントと、ギャップを埋めるのに最適なトレーニング

  • AWS は無料教育も有料トレーニングも、両方やってます
  • 役割の分離を強化するために、IAM グループを使います
  • アカウントを分離しましょう
  • 最も繊細なオペ/リソースについては MFA (AWS Multi-Factor Authentication) を使いましょう
    • Management Console と API から使えます
    • 別々の人に MFA と credentials を使うことを検討しましょう

CC10: ファイヤーウォールやルーターやスイッチのようなネットワーク機器への安全な設定

  • Security Groups
    • ステートフルフィルターです
    • (EC2) ローンチした時点で適用されます
    • VPC内でのみ、起動後に追加することができます
    • ロールベースのセキュリティです
  • ネットワーク ACL
    • ステートレスフィルターです
    • VPC 内における、ロケーションベースのセキュリティです
  • 設定を含めた AWS CloudFormation を使いましょう
    • プロからのtips: さらにサブネットやroute tableなどの全ての VPC が設定可能です

CC11: ネットワークポート、プロトコル、サービスの制限と制御

  • Security Groups と ネットワーク ACL を使って、表面攻撃の影響を最小限にしましょう
  • VPC とパブリック/プライベートサブネットを使ってサーバーの視認性を制御しましょう
  • ホストベースのファイヤーウォールの導入を検討しましょう
  • 自動的に巡回して検出と違反検知を行うスクリプトの導入を検討しましょう
  • ネットワークセキュリティテストの登録を忘れずに!
  • AWS Trusted Advisor が潜在障害の確認に利用できます

CC12: 管理者権限の使用の制御

  • IAM を使いましょう
  • 役割の分離を強化するために、IAM グループを使いましょう
    • 監査のために、読取専用の IAM ユーザを作成可能です
    • サードパーティへは常に IAM ユーザを作成しましょう
  • アカウントの分離を検討してください
  • 最も繊細なオペ/リソースについては MFA (AWS Multi-Factor Authentication) を使いましょう
    • Management Console と API から使えます
    • 別々の人に MFA と credentials を使うことを検討しましょう
  • AWS リソースにセキュアにアクセスする Roles for EC2 を使いましょう
    • credentials のローテーションを自動化しましょう
    • 情報が漏れた場合の影響を最小化しましょう
  • AWS STS はフェデレート識別というユースケースのために AWS STS を使いましょう
  • 定期的にすべての IAM 関連の設定を (WORM-ish)Amazon S3 バケットに書き出すスクリプトの導入を検討してください
  • 注釈
    • IAM はOSでもアプリでもありません

CC13: 境界防御

  • NIDS --> HIDS
  • VPC は旧来からあるDMZ手法をより促進します
  • NAT インスタンスでネットワーク型IDS的なことができます
    • Elastic IP を割り当てたインスタンスで簡単にバイパスできます
  • 要塞化されたインスタンスを使おう!
    • 他のインスタンスへの管理者権限でのアクセスは最小限にしましょう
    • VPN 接続を要求することができます
    • EC2 でも VPC 内でも使えます
    • IDS、ロギング、その他の制御に集中することができます
  • ここまで話したこと全てを思い出してください

CC14: メンテナンス、監視と監査ログ分析

  • いくつかのサービスはロギングをはじめからサポートしています
    • Amazon S3 Bucket Logging
    • Amazon CloudFront
  • 必要なものをキャプチャするために、EC2インスタンスに設定を行ってください
    • リージョンにおける syslog か Windows ロギングターゲットを起動します
      • ロギングターゲットに対してDDoS攻撃しないでください
    • 最後にログを Amazon S3 に移動します
    • ワームっぽいS3バケット上のログの保存を検討します
  • Amazon EMR か他のサードパーティ製ツールで、スケールさせて解析します
    • (たとえば、splunk storm、Papertrail spp、sumo logic、qloudstat、loggly)

CC15: おさえておくべきコントロールアクセスベース

  • データを分類しましょう
  • IAM で役割分担を強化しましょう
  • VPC の分離かアカウントの分離を検討しましょう
  • Amazon S3 暗号化
    • クライアントサイドの暗号化が多くのライブラリに取りこまれています
    • サーバーサイド暗号化は Amazon S3 なら簡単です
  • EBS のデータボリュームはフルディスク暗号化をサポートしています

CC16: アカウント監視制御

  • IAM、Roles for EC2 と AWS STS
    • 役割を分担するIAM
      • 監査と監視用の読取専用 IAM ユーザー
      • サードパーティーのアクセスは全て IAM ユーザーにします
    • Roles for EC2 は、credencials の汚染問題を解決します
    • AWS STS はフェデレイテッド識別のユースケースのためのものです。
  • ワームっぽいS3バケットをロギングしましょう
  • 要塞化インスタンスを使いましょう
  • セキュリティ設定の取得を自動化しましょう

CC17: データ損失の防止

  • VPC の中で出口を制御しましょう
  • 格納されているデータと入出力されるデータの暗号化
  • 要塞化インスタンスの使用
  • ロギング(特に Amazon S3 バケットのロギング)
  • ホストベースIDSと強化されたNATインスタンス
  • たくさんのホストベースDLP製品がインスタンス内で使えます
  • インスタンスから外部向きのSMTPは登録されている必要があります

 https://aws-portal.amazon.com/gp/aws/html-forms-controller/contactus/ec2-email-limit-rdns-request

CC18: インシデントの対応と管理

  • オートスケーリングで時間を買いましょう、行動のために。反応のためではありません。
  • AWS は複数のレベルのプレミアムサポートを販売しております
    • AWS サポートが必要なときだけチケットを開く方式
    • TAM を含むエンタープライズサポート
  • abuse@amazonaws.com にご報告ください
  • aws-security@amazon.com までセキュリティ問題の報告書をご提供ください

CC19: セキュアなネットワークエンジニアリング

  • Security Groups はあなたの仲間です
  • VPC は旧来からあるDMZ手法をより促進します
  • たくさんの古典的な攻撃手法は役立たずです
    • Packet sniffing, IP spoofing などなど
  • 設定の権限を分離するため IAM を使いましょう
  • AWS ソリューションアーキテクトと会話しましょう

CC20: 侵入テストとレッドチーム(攻撃チーム)の訓練

  • 裁量次第でオンホストテストをします
  • ネットワークベーステスト(http://aws.amazon.com/jp/security/penetration-testing/
    • EC2インスタンスのみのテストを実施します
    • AWS API 円dポイントとサービスを提供しています。
  • プロ向け:テスト用に micro や small にインスタンスをスケールダウンしましょう
  • プロ向け:3ヶ月の一時リクエスト