目次
BeeXの榊原です。先日AWSのセキュリティに関する公式トレーニングを受講したので、これについてアウトプットします。公式トレーニングの雰囲気やどんな内容か知りたい方の参考になれば幸いです。事前に講師の方に内容のアウトプットのOKをいただいています。
講座内容
名前にあるとおり、AWSのセキュリティ周りのサービスについて理解を深めるトレーニングです。3日間まるまる詰め込んで実施されるので中々ハードです。
以下、各モジュールごとに簡単な説明とメモを記載します。メモは自分用に記載したものをいくつかピックアップして記載しました。箇条書きで記載しているため、いつもの記事に比べて少々読みにくいですがご容赦ください。コースの雰囲気をざっくり知りたいだけの方は飛ばしていただいて問題ないですが、普段業務でAWSを使われている方は軽く流し読みしてみると、新しい知識が得られるかもしれません。
1. セキュリティの概要
本章はセキュリティエンジニアリングを進めるにあたり、何に注意すべきか解説されていました。。普段業務をしていると、サービスの仕様や設定方法等に目が行きがちなので、改めて話を聞けて良かったです。事前に脅威を洗い出し優先度をつけて文書化する手法、脅威モデリングの具体的な使い方が個人的に勉強になりました。
【メモ】
・セキュリティのガバナンスを実装するためにMSOやMSPを使う
・MSOは社内のセキュリティ管理を実施する部署。MSPは社外のセキュリティ業務の委託先を指す。
・MSOの統制はやりすぎると、クラウドのメリットの1つである俊敏性（すぐ使える）を損なうので注意
2. AWS におけるアクセスと権限付与
APIコールに少し触れ、後は丸々IAMのパートでした。APIコールの部分は個人的にかなり勉強になりました。講師の方が実際にAWS環境を操作し、APIコールの中身を確認するパートがあったのですが、環境を少し動かすだけに毎回こんなやり取りが行われているのかと驚きました。また、IAMについてもAWS STS含めてがっつり踏み込むことが少なかったので、今回理解を深められてよかったです。
【メモ】
・マネコン、AWS CLI、SDK等何を使って操作しようが、その裏ではAWSが公開しているAPIエンドポイントへのAPIコールが行われる
・APIのエンドポイントはリージョナルエンドポイント、グローバルエンドポイントの2つがある。
・APIコールは必ず暗号化されたうえで署名(SigV4)がつく
・APIコールごとに違う署名がつきタイムスタンプがあるため、外部流出しようが他のAPIコールには影響がない
・アイデンティティベースのポリシーはアクセスする側（リソースを操作する側）のポリシー
・リソースベースのポリシーはアクセスを受け付ける側のポリシー（S3バケットポリシー等）
・IAMロールは永続的ではなく一時的なアクセス情報を渡すための仕組み
・一時的なセキュリティ認証情報を提供するにはAWS STSを使う→セキュリティ認証情報が一時的なら、ローテーションも、削除も必要ない
・AssumeRoleはAWSリソースにアクセスするための一時的な認証情報を返すAWS STSのAPI
・STSはAWS内の仕組みであるが、オンプレミスでも利用したい場合はAWS Identity and Access Management Roles Anywhereを利用する
・プログラム等に使用するユーザーアクセスキーについて、漏洩等インシデントが発生した場合削除ではなく、INACTIVEにする。証跡が追えなくなるため
・パーミッションバウンダリーはIAMポリシーと異なり、権限を付与しない。アイデンティティベースのポリシーにフィルタをかけてさらに制限を加えるもの
・複数アカウントを跨ぐ際、Organization SCPやセッションポリシーを使う
・SCPの使い方は例えば、Shield AdvancedやOutposts等の高額なサービスを利用不可にする点が挙げられる
・セッションポリシーはセキュリティ管理者でなく、自ら権限にフィルタをかける仕組み。
・明示的なDenyに引っかかったら、操作は絶対に通らない。必ず防ぎたい操作はDenyで指定。
・ポリシーの評価順序はOrganizations SCP→リソースベースのポリシー→アイデンティティベースのポリシー→パーミッションバウンダリー→特に記載がなければDeny(暗黙的なDeny)。下図はAWS公式ドキュメントより。
【参考URL】
・AWS の API を理解しよう ! 初級編 ~ API の仕組みと利用方法を理解しよう
・API リクエストに対する AWS Signature Version 4
・一時的なセキュリティ認証情報をリクエストする
・AssumeRole
・ポリシーの評価論理
3.AWS におけるアカウント管理とプロビジョニング
マルチアカウント環境やフェデレーテッドユーザーの認証周りについて解説がありました。ラボ（ハンズオン）はAWS Directory Serviceのディレクトリをユーザを使い、AWSのマネジメントコンソールにアクセスさせるいう内容でした。Windows OSの操作も少し絡みました。EC2のADとAWS上のADのユーザ管理が一元化される様子も確認でき、フェデレーションの利点を味わえました。
【メモ】
・上で確認した通り、ポリシーの評価順序で一番最初に評価されるのがOrganizations SCPである。一番最初に評価される＝複数アカウントの統率がとりやすくなる
・複数アカウントを管理する際、AWSのベストプラクティスにそって自動で環境を整えたい場合はControl Tower。高度な管理機能、独自にカスタムしたい箇所が多い場合はOrganizationsを使う。
・最初はOrganizations、その後でConrtrol Towerに追加させることが可能
・Control Towerの管轄からアカウントを切り離す場合は少し面倒。（必須コントロールを止める等が必要）
・IDのリソース管理とAWSのIS管理を一元化することで、ユーザ管理が楽になる（例えば退職者が出た際、会社側のIDリソース管理でDeactivateすればAWS側にも反映される）
4. AWS におけるキーとシークレットの管理
KMS、Cloud HSMを用いた暗号化鍵管理やSecrets Managerを用いた認証情報をどう管理するか学ぶパートでした。KMSの細かい仕様は記憶が曖昧になっていたのでよい復習になりました。
【メモ】
・データを暗号化したデータキーをさらに主キーで暗号化する（エンベロープ暗号化）ことで、主キーの管理をすれば、暗号化したデータを閲覧できるユーザを制限できる。
・KMSキーは主キーを指す
・KMSを用いれば誰がKMSキーを使ってデータを復号したか等CloudTrailで追える
・データを保管するストレージサービスも、データキーを暗号化する主キーの管理もAWSに任せることが許容されないケースもある。その場合はCSEで独自の暗号化キーを作成・管理が可能。Encryption SDKをアプリに組み込んで、オンプレミスのデータキーを暗号化することが可能。ただし、オンプレミスでデータキーを無くすと復号できなくなるため、データキーの管理は慎重に。
・ローテーション後のKMSキーは、ローテーション前の鍵も取っている。どのバージョンのKMSキーで暗号化されたかは全て記録がとられている。ローテーション前の鍵は復号のみにつかわれる。暗号化は現時点のバージョンでしかできない。
・ヘルスケアや金融関係のユーザーはマルチテナントが許容できないケースがある。その場合はCloudHSMを用いる。
・カスタムキーストアを用いてKMSで作成したキーをKMS以外で管理可能。この時CloudHSMを選択可能。
・カスタマー管理キーにはエイリアスを与えられる。
・EventBridge等でEBS暗号化したEC2を起動するとき、EC2の権限だけでなく下記のポリシーも必要
kms:CreateGrant
kms:Decrypt
kms:DescribeKey
kms:GenerateDataKeyWithoutPlainText
kms:ReEncrypt
・Secrets Managerで認証情報のローテーションをさせる際、裏でCFnが動いてLambdaとLambda用IAMロールが作成される。（RDSのマネージドローテーションは除く）
【参考】
・エイリアスの使用
・ローテーション AWS KMS keys
・AWS Certificate Manager
5. データセキュリティ
S3やEBS等のストレージサービスの保護について学びました。なじみ深いサービスが多かったものの、実際どう業務で使うか等の話が多めで聞いていて面白いパートでした。
【メモ】
・S3のデータはデフォルトで無料でSSE-S3で暗号化されるが、鍵の利用証跡が取れないので注意。利用証跡が欲しい場合はコストがかかるが、SSE-KMSを利用する（CloudTrailで証跡取得可）
・S3のACLはデフォルトでは無効でバケットポリシーの利用が推奨されている
・ACLをやむを得ず使うケースもある。たとえばCloudFrontのログを保存する場合。裏側の仕組みとして必要。（awslogsdeliveryがCloudFrontのログを書き込んでいる）
・バケットポリシーだけで制御していくと、大規模運用になった際長文で使いづらくなるため、アクセスポイントの利用が推奨される。部門ごとのアクセスポイントとアクセスポイントポリシーを使う。バケットポリシーを編集した際、他の部門に影響が及ぶといった事象を減らせる。
・S3のオブジェクトロック＝WORMモデル。Write Once Read Manyで書き込みは1回のみ、読み込みは何回でも可能。2つのリテンションモードある。ガバナンスモードは権限があるユーザは保持期間中、オブジェクトの上書き、削除が可能コンプライアンスモードはrootユーザ含め、どのユーザも設定した瞬間保護した期間の間オブジェクトの上書きや削除ができない。
・オブジェクトロックはランサムウェアの身代金対策にも使える。読み取りはできるが、データに対して自由に暗号化して書き込みができなくなるため。
・S3バケットのデフォルト暗号化は、オブジェクトアップロード時に設定を上書きできてしまう。たとえばデフォルトでSSE-S3を指定していても、SSE-KMSでアップロードが可能。これを防ぐためにはバケットポリシーを編集する必要あり。（よく使う手法）
・DynamoDBのテーブルの暗号化オフは不可能。必ず暗号化される。
・DynamoDBのグローバルテーブルはマルチマスター。どこに書き込んでも低遅延で変更が反映される。Zoomやディズニー+にも使われている。
【参考】
・標準ログ (アクセスログ) を設定および使用する
・Amazon DynamoDB グローバルテーブル
6. インフラストラクチャとエッジ保護
AWSで安全なインフラストラクチャを実現するためにはどうするか学ぶパートです。セキュリティグループやNACLに始まり、Network FirewallやVPCエンドポイント、後半はCloudFrontやRoute53、WAFも登場しました。ラボはWAFを使ってHTTPフラッドとSQLインジェクションを防止しようという内容でした。元ネタはAWSのソリューションライブラリで公開されているものなので、興味がある方はこちらから試してみてください。
【メモ】
・ALBは固定IPを対応していないので、固定IPで接続したい場合は前にEIP付きのNLBを配置する
・Route53のSLAはなんと100%。（Amazon Route 53が月間請求期間中のサービス使用者のDNSクエリに対して応答しないことがない状態）実現させているのがシャッフルシャーディングとエニーキャストストライピング。
7. AWS におけるログのモニタリングと収集
全部書ききれないくらい、たくさんのサービスが登場しました。代表的なものはCloudTrail、CloudWatchあたりでしょうか。ConfigルールでAWSリソースが修正されている様子や、Detectiveの調査結果や使い方を講師の方が画面共有で見せてくれたため、利用イメージは沸きやすかったです。
【メモ】
・VPCフローログはベストエフォート型。全部のENIを通過するパケットがとられるわけではない。
・ハイブリッド構成でAWSのEC2と疎通できないときにまずVPCフローログを見る。オンプレから通信が届いているか確認し、届いていたらその内容を見る。ActionがREJECTならSGやNACLで防がれており、ACCEPTならOSのサービスが止まっているといった判断が可能。
・VPCフローログはパケットの中身まで見れない。tcpdumpやWiresharkのような機能を使いたい場合、VPCトラフィックミラーリングが使える。ただし、EC2の通信を圧迫するので注意。
・S3のサーバアクセスログはベストエフォート型のため、全部のアクセスログが取れるわけではない。可能な限り取得したい場合はCloudTrailのデータイベント（取得は有料）と併用して保管する。
・Athenaの分析環境をすぐ整えたい方は自動インテグレーションのCloudFormationテンプレートがある。こちら
・OpenSearchを使いたい方はソリューションライブラリにテンプレートがある。こちら
・CloudTrailやVPCフローログ、GuardDuty等のログから、機械学習や統計を使って分析して結果を教えてくれるサービスがDetective。
・Configはリソース構成の関連性を追うのが得意。（記事化したい）
8. 脅威への対応
インシデントの対応策に関するパートです。一番印象的だったのが講師の方が見せてくださったDetectiveのデモでした。GuardDutyで脅威が検出された場所を、都道府県単位で座標付きの位置情報含めて表示されることを確認しました。ラボでは実際に攻撃を受けたEC2がある状態で、どのように現環境と切り離してフォレンジックまでもっていくかハンズオンで体験することができました。
【メモ】
・SSMAgentにはInspectorのAgentが含まれている
AWS Systems Manager Agent: With the new Amazon Inspector, you no longer need to install and maintain a standalone Amazon Inspector agent on all of your Amazon EC2 instances. The new Amazon Inspector uses the widely deployed AWS Systems Manager Agent (SSM Agent), which removes that need.（引用元：Amazon Inspector FAQs）
・GuardDutyをオンにすると、AWSやサードパーティの専門チームが協力して作った脅威インテリジェンスソース（脅威の情報がまとまったもの）を使って機械学習でAWSアカウントの異常やいつもと違うふるまいを検知してくれる
・GuardDutyのマルウェアプロテクションの仕組みは、疑いのあるEC2のスナップショットを取得し、GuardDuty用のアカウントに送ってその中でマルウェアスキャンを行っている。
感想
講師の方が実際にどうサービスを使っていたか、似たサービスがある際の選定基準にフォーカスした話もあり、普段AWSの業務に携わる自分としてはありがたい内容でした。加えていつでも質問できるのも良かったです。総合的な感想としては丸３日連続は大変でしたが受講して良かったと思います。あえて不満点を挙げるのであれば、もう少し座学の時間を削って手を動かすラボが欲しかった点、結構高額な点でしょうか。
また、これはあくまで個人の意見なのですが、内容をきちんと消化するためにも、AWSの経験（特にインフラ周り）が最低でも1-2年はあるとよいかと思います。試験対策や初めてセキュリティ系のサービスに触れるために予習するために利用するよりは、実務で得た経験・知識をさらに深めるために受講されるのが得るものが多くなると思います。
ここまでお読みいただきありがとうございました。受講を迷っている方の参考になれば幸いです。
この記事をシェアする
