AWS Shield
# AWS Shield
https://d1.awsstatic.com/webinars/jp/pdf/services/20170718_AWS-BlackBelt-Shield.pdf
## DDos 対策
DDos とは: Distributed Denial Of Service(ネットワークを通じた攻撃手法の一種で、標的となるコンピュータに対して複数のマシンから大量の処理負荷を与えることでサービスを機能停止状態へ追い込む手法のこと)
- ユーザーができるDDoS対策
- 攻撃対象領域を削減する
- スケールして攻撃を吸収できるようにする
- 公開されたリソースを保護する
- 通常時の動作について学習する
- 攻撃に対する計画を作成する
- AWSには標準でDDoS防御が組み込まれている
- セキュリティの脅威タイプ
## AWS Shield とは
AWS Shield はDDoSに対しての対策を行ってくれる
- 種類
- Standard Protection
- 全てのAWSユーザに適用
- 無料
- Advanced Protection
- より大規模な、より洗練された攻撃からの防御を提供する
- 有料のサービス
- AWS Shield Standard
- Layer 3/4 Protection
- 一般的な攻撃からの防御
- 自動検知＆自動緩和(DDoSのアクセスを90%以上軽減)
- AWSサービスにビルトイン済み
- CloudFront, Route53エッジロケーションの前にインラインで配置されて全てのパケットはAWS Shield を通るようになる
- Layer 7 Protection
- Layer 7 のDDoS攻撃への緩和はAWS WAFで行う
- セルフサービス
- AWS Shield Advanced Protection
- 対象サービス
- CLB
- ALB（インクルードされているWAFによる対応）
- CloudFront（インクルードされているWAFによる対応）
- Route53
- DDoSへの対策
- DDoS Response Team
- L7 DDoS Protection
- AWS WAFによる保護
- Cost Protection
- DDoS 攻撃によるスケーリングコストを回避
- Advanced Mitigation
- DDoSのトラフィックを軽減してくれる
- DDoS Response Team が手動でセットアップしてくれる部分もある
- L3/4での軽減
- L7 での軽減
- Reporting
- CloudWatch を経由してリアルタイム通知
- ニアリアルタイムメトリクスと攻撃のフォレンジクスのためのパケットキャプチャ
- 時系列の攻撃レポート
- Operation
- Self-Service
- WAFが追加費用なしで含まれる
- 攻撃の通知、フォレンジック、履歴レポート
- DDoS エキスパートによる対応
- 積極的なDDos Response Team の関与
## AWS Shield オペレーションとは
- AWS Shield Advanced を利用するまでのステップ
## AWS DDoS Shield の使い分け
- Standard Protection
- Advanced Protection
- 大規模な攻撃に対する防御
- 攻撃に対する可視性
- 複雑なケースでのDDoSエキスパートによるサポート
## 雑感
AWS のDDoSに対する防御と検知を提供するサービス。基本的なDDoSは無料で組み込まれているので十分と言えそうだが、より高度な攻撃に対応したい場合や、サポートが必要な場合はAdvanced Protection を入れる感じになる。とはいえ、月30万 で一年間利用をコミットしないといけないので判断はする必要がある。
AWS Sheild Advanced Protection にはWAFが付属していてこれによりDDoSだけではなくApplication Attack とBad Bots への対策にもなる。AWS Shield 自体は対応するリソースの前段で動き、悪意のあるトラフィックを検知・軽減してくれる。
AWS Directory Service
# AWS Directory Service
https://d1.awsstatic.com/webinars/jp/pdf/services/20151021_aws-blackbelt-directory-service.pdf
## ディレクトリとは
- ユーザに関わる各種情報を保管する仕組み
- ユーザー名
- 姓・名・部署・電話番号
- メールアドレス
- グループ
- パスワードなど
- ツリー状の構成をすることからディレクトリと呼ばれる
- LDAP、AD、OpenLDAP
- Active Directory とは
- Windows ネットワークの基本的な認証とセキュリティ基盤
- Windows 2000から標準機能として実装されたディレクトリサービス
- Active Directory の必要性
- Active Directory ドメインサービス
## AWS Directory Service
- Active Directory on AWS
- フルマネージド型のディレクトリサービス
- 既存のAD認証を利用して
- ディレクトリタイプの選択（ディレクトリのサイズ選択によって最大ユーザー数の上限が決まっている）
- Simple AD
- AWS上の新規ディレクトリ
- フルマネージドのディレクトリサービス
- AWS上に独立したドメインを作成
- Samba 4 互換
- AD Connector
- Simple AD
- Microsoft AD
## AWS Management Console との認証フェデレーション
- Active Directory フェデレーションサービス（ADFS）
- SSOの提供
- AC Connector によるフェデレーション
- ADユーザーはaccess URL 経由でコンソールにログイン
- MFAを設定できる
- ログイン先からさらにクロスアカウントアクセスでSwitch Role できる
## AWS アプリケーションとの連携
- シングルサインオンの有効化
## 雑感
AWSのAD統合サービス。フルマネージドなSimple AD か、AD Connectorで既存のADと連携させるかを選べる。社内システムやアプリケーションをSSOで管理できるようになり、セキュリティや効率が上がる。Linux の場合でもツールをインストールすることによってADドメインに入ることができる。
Azure AD と競合している。Azure AD とAWS Single Sign-On でAWSアクセス許可を一元管理することができる。Azure AD は標準の規格に加えて様々なカスタマイズができるようになっているようなので、シンプルに運用してAWSに寄せたいのであればAWS Directory Service 、それ以上に柔軟に設定・運用したい場合はAzure AD が選ばれるのではないかな。
AWS Key Management Service
# AWS Key Management Service
https://d1.awsstatic.com/webinars/jp/pdf/services/20181121_AWS-BlackBelt-KMS.pdf
## KMS 概要
- 暗号の鍵管理において考慮すべき問題
- 鍵の保存先
- 鍵はどこで扱われるのか
- 誰が鍵を使えるのか
- Key Management Infrastructure
- AWS Key Management Service
- KMSで登場する用語
- Customer Master Key(CMK)
- 暗号鍵のヒエラルキーの頂点に位置するKMS上のAWS256ビットの鍵
- 暗号化された状態で保存
- KMS内部のHSM上でのみ平文で存在する
- この鍵を利用して個別データの鍵を暗号化する
- Enveloper Encryption
- マスターキーで暗号した暗号キーで対象オブジェクトを暗号化・復号する
- 暗号化したデータと、CMKで暗号化されたデータキーを一緒に保管する。コンテンツに対する封筒
- 大量データの暗号化を実現
- 管理性の向上
- Customer Data Key(CDK)
- 実際の暗号化対象オブジェクトの暗号化・復号化に使用されるAWS256ビットの鍵
- KMSで生成され、CMKで暗号化された状態で保存
- AWS KMS でできること
- できること
- 暗号鍵の生成と保管
- 鍵利用の権限管理
- 鍵利用の監査
- 対象鍵暗号
- 最大4KBのデータ暗号化
- 他のAWSサービスとのインテグレーション
- 鍵のインポート
- できないこと
- シングルテナント
- 非対称鍵暗号
- 鍵のエクスポート
- AWS KMSの暗号鍵管理機能
- 鍵の生成
- 鍵のアクセス管理
- IAMユーザおよびロールの定義
- キーポリシーによるリソースベースの管理
- CMKの無効化・有効化・削除
- 自動キーローテーションの有効化
- ライフサイクルは利用者が管理
- CMKのインポート
- KMSの認可・監査
- AWS KMSの鍵を使用した暗号化・復号化
## ベストプラクティス
- 認証と認可
- IAMポリシーとキーポリシーでデザイン
- 最小権限の原則
- MFAの利用と検討
- 発見的統制
- CloudTrail の利用
- パフォーマンスとサービス制限
- インフラストラクチャのセキュリティ
- インシデント対応の明確化と自動化
- AWS KMSセキリティの自動化
- CMKの無効化と削除
- 他のAWSサービスとの連携
- 暗号化オプションはONにする必要がある
- 暗号化されたバックアップは共有が可能（リージョン間で渡すことはできない）。その場合はCMKの共有もしないと復号できない
- 対応しているインスタンスタイプ（RDS, EBSなど）注意が必要
- 暗号化しているものを途中で暗号化しないに変更することはできない
- KMSのセキュリティ
- 鍵の管理はユーザーが行う
- マスターキーには誰もアクセスできない
- KMSサービス内でアクセスする方法を限定する
- キーは指定されたリージョンにのみ保存され、他のリージョンに移動できない
- キーの1年毎の自動ローテーション。インポートされたキーは対応していない
- CloudTrail による監査
## 雑感
混乱しやすいHSMとKMSのKMSの方。サーバーサイドの暗号化は他のAWSサービスにインテグレーションしやすくなっている。
マスターキーとコンテンツを復号するキー、コンテンツの3つの要素から成り立っていて、マスターキーはコンテンツを暗号化した暗号鍵の暗号化のみに利用される。暗号化された暗号鍵を暗号化したコンテンツと一緒に管理することにより、管理をシンプルにしている（Enverope)。
暗号化されたデータはコピーや共有に制限があったり、CMKの共有が必要であったりするので利用する際には制限の部分に注意する必要がある。
基本的には仕組みに乗っかれれば、キーの管理も自動で行ってくれるので良きサービス。
AWS CloudHSM
# AWS CloudHSM
https://d1.awsstatic.com/webinars/jp/pdf/services/20190723_AWS-Blackbelt-CloudHSM_A.pdf
## 暗号技術概要
- 共通鍵暗号
- 暗号化と複合化に同じ鍵を使う
- 高速に処理可能
- ストレージの暗号化に利用されることが多い
- AESが代表的な暗号方式
- 公開鍵・秘密鍵暗号
- デジタル署名
- デジタル証明書
- 公開鍵を広範囲に使用する際に使われる公開鍵とその所有者を特定する情報を結びつける証明者
- CA認証局が発行しデジタル署名している
- 暗号技術における暗号鍵管理の重要性
- 暗号技術において暗号鍵を安全に保管し、アクセス管理することは重要な課題
- 暗号鍵を管理するためのインフラストラクチャーを利用するのが一般的
- KMI（Key Management Infrastructure）
- HSH（Hardware Security Module）
## AWS における暗号鍵管理
## AWS CloudHSM
- 機能
- VPC内で稼働するサービス
- リージョンサービス
- 2017年にCloudHSM v2 がリリース
- 暗号鍵を保存するための専用ハードウェア
- サポートされる暗号方式
- 鍵の管理と複合の手法
- マスターキーをキーストアに格納し、実際のデータを暗号化、複合するためのデータキーはマスターキーで暗号化しておく。
- 暗号化や複合の際にはKMSまたはCloudHSMに鍵の使用リクエストをAPIで送信し、データキーを一時的に複合かして暗号化、複合する
- 安全性
- 全てのコンポポーネントの品質が担保されており、甚だしいセキュリティの欠如がない
- 物理的な改ざんへの耐性を持ち、また改ざんの際に痕跡が残る
- 強固な筐体
- 筐体を無理やり開こうとするとゼロリセットされる
- 電磁波に対する耐性
- オペレータの役割ベース・IDベースでの認証
- 重要なセキュリティパラメータはモジュールに入出力するインターフェースとその他のインターフェースを物理的または論理的に分離する
- ユースケース
- KMSのカスタムキーストアとして使用
- AWS KMSのカスタママスターキーをCloudHSMクラスタに保管する機能
- 透過的にCloudHSMを使用できる
- AWS KMS標準キーストアはマルチテナントにキーを保存するが、CloudHSMのカスタムキーストアはキーをVPC内に専用のインスタンスを立てて保存するため、よりセキュアになる
- SSL/TLSの暗号化、復号化処理のオフロード
- CA局の秘密鍵管理
- OracleDBのtransparent Data Encryption（透過型暗号）
- ファイルやデータへのデジタル署名
- デジタル権限管理
- CloudHSMをサポートするサードパーティソリューションとの統合
## AWS CloudHSM の管理と運用
- ユーザー管理
- CloudHSM CLI ツール経由でコマンドを発行できるユーザはAWS IAM とは別管理
- HSMクラスタにログインする処理を行う（IAMと透過的には認証認可してくれない）
- ユーザーには3種類のタイプがある
- CloudHSMクォーラム認証
- 複数の認証されたユーザーが承認しないと操作ができないモード
- オンプレミスHSMからCloud HSMへの鍵の移行
- 移行ガイドが存在
- 移行する鍵も暗号鍵をラップするなどして搬送中の鍵を保護できる
- スケーラビリティ
- Cloud HSM v2になってからスケーリングが可能に（ただし手動）
- 上限緩和後は最大28台まで増やせる
- CloudWatch メトリクスで監視
- ノードを追加時には既存のノードのバックアップイメージをリストア
- データの伝播はクラスタ間でいい感じにやってくれる仕組みがある
- バックアップ
- 監査
- CloudTrail に記録できる
- 各インスタンスのメトリクスを出力可能
- 監査ログ
- 自動的に取得され、CloudWatch Logsに出力される
## 雑感
AWS によるマネージドな鍵管理サービス。KMSはマルチテナントでAWSが管理を行ってくれる。Cloud HSMはKSMより強固なセキュリティを担保したい場合に専用のクラスターをin VPC で用意して自前で運用していく必要がある。
KMSは他のAWSサービスとシームレスに連携を行ってくれるのでこれで要件を満たせるのであればこちらを採用したい。もっとビジネス的な要件があった場合にCloud HSMの利用を検討する感じになるかと思う。ただ、運用しなければならないのと、セキュリティをとったことで使い勝手が悪かったり、制約があったりする。その場合は全てをCloud HMSにするのではなくKMSを暗号化するマスターキーをCloudHSMで管理するといったことで対応できないかを考えることをまず初めにするのが良さそう。（KMSの方のBBもあとで読むので比較したい）
AWS Certificate Manager
# AWS Certificate Manager
## 通信をセキュアにする時代
- TLSサーバ証明書を利用する理由
- 脅威
- なりすまし、盗聴、改ざん、否認
- 対策
- 特定：TLS通信を行うウェブサイト、アプリケーション、その他リソースの特定
- 暗号化：安全なネットワーク通信
- 視認：ブラウザユーザーに鍵アイコンを見せる
- PKI(Public Key Infrastructure / 公開鍵暗号基盤)
- 電子証明書とルートCA
- 証明書発行の流れ
- 証明書の発行
- ルートCAがすべての証明書を発行するのは現実的ではないのでCAに移譲して発行している
- トラストチェーン
- CAの適切性を階層的に確認していくことで最終的に正しさを確認できる
- 証明書の正当性確認
- 相手の証明書の正当性を確認するには、適切な組織によって証明されているかを確認することになる
- 認証の種類
- 自己署名証明
- 企業内証明
- 社内用にプライベートCAを作成し、TLSプライベート証明書を発行
- ドメイン認証（DV)
- 組織認証（OV)
- 組織情報の審査を経てから発行
- 拡張認証（EV)
- OVよりも厳格な審査を経て発行
- TLSサーバ証明書の運用上の課題
## AWS Certificate Manager(ACM)
ACM を利用するとAWSクラウド上でTLSサーバ証明書のプロビジョニング、管理、展開、更新が容易
- ACMの機能
- 発行機能
- 展開更新機能
- 発行した証明書の展開
- インポートした証明書の展開
- 対象サービス
- ELB
- Amazon CloudFront ディストリビューション
- Amazon API Gateway 上のAPIカスタムドメイン
- EC2やオンプレサーバ等の内部リソース（プライベート証明書）
- コンソール、API、SDK、CLI
- メリット
## AWS Certificate Manager Private CA
- プライベートCA運用における課題
- プライベートCAの維持は複雑で効果
- セキュリティの知識も必要
- 複数CAの運用は複雑
- 動的リソースで利用したい場合スケーラビリティ考慮必要
- ACMは動的リソースのどのような問題を解決できるか
- ACMでできること
- セキュアかつマネージドなプライベートCA
- ハードウエア セキュリティモジュール
- IAM
- 証明書失効リスト（CRL）
- 監査レポート出力
- 証明書の集中管理
- API
- プライベート証明書のカスタマイズ
- 従量課金
- 仕組み
- ユースケース
- ACM Private CA証明書発行管理方法
## 雑感
AWSの証明書発行・管理サービス。ACMとACM Private CAの２つがあり、インターネットに公開するパプリックCAと社内などのインターナルで利用するPrivate のCAがある。
ACMの利点としては証明書の自動更新や、組み合わせることで自動化できるところにあると思う。（証明書の更新忘れでs◯ftbank が繋がらなく
Amazon Macie
## Amazon Macie とは
- 概要
- データソース
- S3
- CloudTrail
- EBS
- RDS
- DynamoDB
- EFS
- AWS Glue
- 使い方
- CloudTrail を有効にする
- Macie で保護するS3バケットの追加
- Macie が利用するIAMを作成する（CFnテンプレートがある）
- データの分類方法（リスクレベルを次の観点で分類し、決定する）
- コンテンツタイプ
- ファイル拡張し
- テーマ（英語のみ対応）
- 正規表現
- 個人情報
- Support Vector Machine ベースの分類
- アラート
- アラートレベル
- Critical ~ High ~ Medium ~ Low ~ Info の5段階
- 種類
- 基本アラート
- 予測アラート
## ユースケース
- 機密データの検出
- 企業内での不正アップロードの検出
- 不正アクセス・攻撃の検知
- 不注意な捜査への警告（オープン権限）
- 監査
- クロスアカウントでの監視（他社の保持するデータに対して）
## 雑感
Macie はもう東京リージョンにも来ていて利用することができる。ただ、まだ日本語には対応できていないようなので、それ以外の機密情報の流出を監視・検出したい場合には良さそう。値段についてもリリースされた時期よりかなり安くなったみたいだし。（https://aws.amazon.com/jp/blogs/aws/new-enhanced-amazon-macie-now-available/）
クロスアカウントでチェックできることと、Credential を確認してくれるのは嬉しい。CloudTrail はユーザの操作に対して焦点が当てられていてAmazon Macie はデータの漏洩に対して焦点が当てられているイメージ。
Amazon Inspector
# Amazon Inspector
https://d1.awsstatic.com/webinars/jp/pdf/services/20160622_AWS_BlackBelt-Inspector-public.pdf
## セキュリティ診断について
セキュリティリスクは
脅威 x 脆弱性 x 情報資産の掛け合わせで算出される
このうち脆弱性については自分たちの対応次第で管理することが可能な項目
- レイヤー
- Webアプリケーション診断
- Web アプリケーション
- プラットフォーム診断
- OS / ミドルウエア
- ネットワーク
- トポロジー
## Amazon Inspector とは
Amazon EC2にエージェントを導入し、プラットフォームの脆弱性を診断するホスト型診断サービス
AWS リソースに対するオンデマンド・自動的・詳細なセキュリティ評価サービス
- Amazon Inspector が提供するもの
- システム設定や振る舞いの分析エンジン
- 組み込みのルールパッケージ
- CVE(Common Vulnerabilities & Exposures)
- EC2インスタンスがCVEに晒されているかをチェック（リストは自動更新される）
- CIS(Center for Internet Security)
- OSのセキュリティ設定ベンチマーク
- セキュリティのベストプラクティス
- 実行時の振る舞い分析
- 推奨対応手順が含まれた詳細レポート
- API連携による開発プロセスとの統合
- AWSエージェント条件
- パブリックエンドポイントへのネットワーク
- インストールにはOSの管理者権限が必要
- 使いどころ
- 設計開発時
- 継続的なデプロイ＋セキュリティ評価を行っていける
- 本番運用時
- Auto Scaling にも対応
