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の2つがあり、インターネットに公開するパプリック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 にも対応
Amazon GuardDuty
# Amazon GuardDuty
https://d1.awsstatic.com/webinars/jp/pdf/services/20180509_AWS-BlackBelt_Amazon-GuardDuty.pdf
## AWS のセキュリティサービス
- 発見的統制
- CloudWatch
- CloudTrail
- GuardDuty
- セキュリティ脅威リスクを検知・可視化
- 悪意のあるIPアドレス、異常検出、機械学習
- 統合脅威インテリジェンスを使用した脅威検知
- インフラストラクチャー保護
- データ保護
- インシデントレスポンス
- リスクコンプライアンス
- ID・アクセス管理
## Amazon GuardDuty
- 脅威検出を目的としたマネージドサービス
- 機械学習による、異常検知のしくみ
- EC2またはIAMに置ける脅威を検出
- 東京リージョン
## GuardDuty Service Components
- Threat Detection Types
- 悪意のあるスキャン
- インスタンスへの脅威
- アカウントへの脅威
- Data Sources
- Trusted & Threat IP Lists
- Findings
- 脅威または潜在的な攻撃リスクの主な目的
- Backdoor
- AWSリソースが攻撃を受けていることを検出
- Behavior
- ベースラインとは異なるアクティビティやアクティビティパターンを検出
- Crypto Currency
- ビットアコインやイーサリアムなどの暗号通貨に関連づけられたソフトウェアを検出
- Pentest
- 既知のペンテストツールで生成されたアクティビティと類似するアクティビティを検出
- Recon
- Stealth
- 攻撃アクションや形跡を隠そうとするアクティビティを検出
- Trojan
- トロイの木馬プログラムが攻撃に使用されていることを検知
- Unauthorized Access
- 不審なアクティビティまたはアクティビティパターンの検出
- 重要度によってSeverity を設定している
- High
- Medium
- Low
- Princing
- AWS Accounts
- 他のAWS アカウントに集約したり、Findingを他のアカウントのGuardDuty に転送・統合管理することが可能
- CloudFormation でプロビジョニングも可能
- サンプル( https://github.com/aws-samples/amazon-guardduty-multiaccount-scripts )
## 雑感
既存のアプリのレイテンシーを上げることなくセキュリティレベルを上げることができるマネージドサービス。シンプルに利用するのであれば、ホワイトリスト型のIP制限を行うということが考えられる。
させることが多くなるとその分Log が大きくなり、料金もかさむがしっかり検知できるようになる。
API キーがリークしていてEC2が勝手にビットコインのマイニングに利用されていたりすることを検知してくれるのはありがたい。
Amazon Cognito
# Amazon Cognito
https://d1.awsstatic.com/webinars/jp/pdf/services/20170517_AWS-BlackBelt_AmazonCognito.pdf
## AWS のモバイルサービス
- ユーザー認証、アクセス許可
- Amazon Cognito(Identity)
- データ同期
- Amazon Cognito(Sync)
- ログストリーム
- 行動分析
- ビジネスロジックの実行
- AWS Lambda
- RESTful API サーバー
- メディアの管理
- メディアの配信
- プッシュ通知の送信
- チャットボット
- Amazon Lex
- 共有データの保存
- DynamoDB
- 実機テストの並列実行
- DeviceFarm
## Amazon Cognito とは
## Congnito Identity
### Your User Pools
- マネージドなユーザー管理サービス
- 認証を担当
- MFAオプション、パスワードポリシー、ユーザーのグルーピング、認証フローをサポート
- ユーザーの操作
- ユーザのサインアップとサインイン
- ユーザプロファイル
- パスワード紛失
- トークンベースの認証
- Email or 電話番号による確認
- SMS ベースのMFA
- AWS Lambda を利用した認証のカスタマイズ
- 管理者の操作
- ユーザプールの作成と管理
- 属性の定義
- 必須属性データの要求
- アプリのパーミッション
- パスワードポリシーのセットアップ
- ユーザーの検索
- ユーザーの管理
### Federated Identities
- 概要
- 認可を担当
- 認証は外部Identityy Provider 等に移譲
- 未認証ユーザーにUnauth Identity としてゲスト用権限(IAM Role)を払い出すことも可能
- 1人の人間が持つ複数のIdentity Provider のアカウント情報をIdentity としてまとめる(=Federation)
- AWS リソースへのアクセス権の管理(Temporary Credential はIAM から発行している)
- ロールベースのアクセコントロールでIdentity IDごとに制御することも可能(自分のリソースだけにアクセスさせるようにしたい)
- 概念
- Identity
- 複数IDプロバイダーのアカウント、複数デバイスを持ちうる1人のユーザ
- IdentityID
- Identity に付与されるID
- IdentityPool
- Role等の紐付けを設定するプール。大抵の場合1つのアプリまたはサービスに相当する単位
- 未認証アクセスのON/OFFの設定
- Authenticated Role
- 認証済みIdentity に付与する権限を定義したIAM Role
- 1つのIdentity Poolにつき1つ設定
- Unauthenticated Role
- 未認証Identity に付与する権限を定義したIAM Role
- Authentication Providers
- Identity Pool に紐づける認証プロバイダ
## Coginito Sync
- 概要
- Federated Identities のIdentity が持つ複数デバイス間でデータの同期を担当(データ共有ではない)
- オフラインサポート
- バックエンド不要(シンプルなクライアントSDKの形で提供)
- データ同期実行時にPush Sync、Cognito Streams、Cognito Events などの処理を連動させることも可能
- 同期処理
- Synchronize
- 接続が不安定になるときの処理の実装は自身で行わなければならない
- コールされるとクラウド上の変更がPull され、ローカルの変更がPush される
- Syncronize on Connectivity
- 実行時に接続可能であれば通常のSynchronize メソッドと同様の振る舞いをする
- 接続できなかった時は接続状態を監視し、可能になったときに同期を行う
- 複数回呼び出された時は最後のオペレーションがキープされる
- Amazon Cognito Push Sync
- SNS Mobile Push との連携
- Mobile Push を受け取ったアプリはデータストアの再同期を行うといった処理が可能
- Amazon Cognito Stream
- Amazon Cognito Events
- Amazon Lambda との連携
- データが更新されたタイミングで発火し、サーバーサイドで登録データのバリデーションや加工を行う処理をLambda に行わせることができる
## 雑感
Cognito 自体が今まで認証・認可のサービスという認識で深くは知らなかった。
Identity Pool が認証を担当し、Federated Identity がIAM やIdP プロバイダに問い合わせを行い認可を行うという構図が掴めて理解が深まった。
デバイス間の同期のあたりもCognito を介して行うことができるので複数デバイスで複数のプラットフォームを利用したい場合には絶対に利用することになるサービスになる。モバイルだと電場が不安定になる場合もあるので実装上は注意が必要というのもわかってはいるが、なかなか丁寧にエラーハンドリングしないといけないので難しそう。。。
認証の仕組み自体が、いろいろな場所に問い合わせを行う形になっているので実装を通して理解する感じになると思う。