この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
みなさん、AWSのセキュリティ対策してますか？(挨拶
ついにやってまいりました、DevelopersIO 2021 Decade！私は「[2021年版]AWSセキュリティ対策全部盛り[初級から上級まで]」というテーマで登壇しました。
動画と資料と解説をこのブログでやっていきます。
動画
資料
解説
動画はちょっぱやで喋っているので、解説は丁寧めにやっていきます。
タイトル付けの背景
今回何喋ろうかなーって思ってたら、2年前のDevelopersIOで喋ったやつを見て、そろそろブラッシュアップしようと思いました。
全部盛りって結構みんな使いたい内容だと思うんですが、なんか誰も作ってくれないので自分でまとめています。150枚のスライドで。
実際私はこの2年くらいで何度このブログを開いて中身を見たかわかんないくらい見て、何度も色んな人に配りました。
ただ流石にいろいろ増えたなーと思ったので書くことにしました。まあブラッシュアップだし適度に楽でしょって思ってました。
で、いざスライド作り始めたら結局ほぼ1から全部作りました。200枚のスライドを。
これが全部盛りの宿命ですな。
2019のときも今回も45分で喋るので2倍速ぐらいで喋ってます。
とりあえずここで色々解説しますが、詳しく聞きたい方は言ってください。いくらでも喋ります。
セッションテーマ
「すべての人にセキュリティを」
気がついたら私はAWSに携わり始めてから4年半位たったのですが(だいぶ新参ですが)、AWSに関わる人はすごく増えてるなーと感じています。
いい面もあればいろんな課題も感じていて、AWSをやっている人だけでなく、周りのAWSに関わるすべての人も含めて、色んな人にセキュリティを届けたいなー、となんとなくそんな感じで決めました。
アジェンダ
- 長い前説
- [初級]AWSを始める、セキュアに
- [初級]システム作る、セキュアに
- [中級]AWSのセキュリティを維持する
- [中級]インシデントに対応する
- [上級]組織全体でガバナンスを効かせる
初級から上級までということでその段階に合わせて章立てしました。いろんなレベル感の話が続くので、自身のレベルに合ったところに目次(表示されていれば)を使って飛んでもらっても構いません。あ、長い前説は全員見てください。
結果、動画では初級とかは特にほぼ飛ばして喋っているので記事では適度にしっかり書いていきます。
ちなみに上級といいつつ本当の上級かはわかりません。何が一番むずかしいかなー？全部盛りと言いましたが、実際全部なんてものは定義できないので全部ではありません。「○○が無いやん、どうなってんの？」と思う方は追撃ブログ書いて、どうぞ。
1. 長い前説
長い前説は以下のような理由からつけています。
- AWSのセキュリティのまえに情報セキュリティ
- 小手先の技術より根本的なセキュリティの考え方
- なんのためかわからないセキュリティではなく正しく意味のあるセキュリティ
- 後付けのセキュリティではなく設計から組み込まれたセキュリティ
- ひとりで頑張るではなく全員で取り組む
- 人力で頑張るではなく精度の高い機械に任せる
- オンプレミスの代わりではなくクラウドの恩恵を受ける
いきなりAWSのセキュリティの話をしても、上記のようなところを理解していないと仕方ないのでこういった要素についてまず説明します。長いですがこれらを押さえると、意味のある取り組みができます。
セキュリティで守るもの
何を守るためにセキュリティ対策しますか？というところからです。何を守るかを理解しなければセキュリティ対策は始まりません。
例えば以下のような観点があります。
- データ
- 機密情報
- 顧客データ
- 個人情報
- クレジットカード
- コンテンツ
- 利用者
- 個人情報
- アップしたコンテンツ
- 会社
- 業務システム
- 会社自体
- 企業イメージ
- 従業員
- お金
ではこれらの守りたいものはどこにあるのか？きちんと把握できていますか？例えば以下のようなものがあります。
- サーバー
- データベース
- ストレージ
- PC
- 物理的な紙
これらの守るものは資産です。大事なことは資産の把握です。以下のような観点を整理していきます。
- どこにあるのか
- 誰が責任者か
- 誰が管理しているのか
- 誰がアクセスできるのか
- 今すぐに状態がわかるか
資産の洗い出しをして・管理していきます。
脅威とリスクを理解する
情報セキュリティで扱う脅威は以下のようなものがあります。
- 情報漏えい
- 金銭の搾取
- サービス停止
- 改ざん
- なりすまし
これらの脅威は外的なもので基本的にコントロールできません。(内部不正などの内的な脅威はある程度コントロール可能です。)一方、これらの脅威は脆弱性と合わさることでリスクが顕在化します。脆弱性はコントロール可能なので、これを減らしていくことがセキュリティ対策のアプローチの1つです。
そして資産の価値も掛け合わせてリスクの大きさが変わります。リスクに応じて対策を検討していきます。
具体的なリスクとして「サーバーのデータが漏洩する」ことを考えてみます。この根本対策はアクセス制御を徹底することが上げられます。一方で補助的な対策としてDLP製品の導入などがあります。対策の順序としては根本対策が先になります。アクセス制御がおろそかなのにDLPを入れても意味がありません。
このようにリスクも洗い出し、どのようなことをやっていくかを考えていく必要があります。
資産を洗い出し、リスクを洗い出し分析したら優先順位が見えてきます。
セキュリティの責任は誰にあるか？
A. 全員です。当たり前ですね。
セキュリティはすべてのものに組み込まれる当たり前の要素です。ブレーキのない車は欠陥品ですよね。
セキュリティ担当者は特にセキュリティに強い関わりを持つだけで、開発者・運用者・監査人・経営者など他の人がセキュリティの責任を持たないことはありません。つまり全員セキュリティ担当ですね。もちろん必要な人が必要な範囲取り組んでいけばいいです。
というわけでひとりでセキュリティ対策できるわけないですよね。みんなで取り組みます。
知識と情報
取り組むためには基本の知識と最新の情報が必要です。
セキュリティの原則は以下のようなものがあります。これらを押さえながら対策します。
- 最小権限
- 多層防御
- 識別・認証・認可
- システムの堅牢化
- フェールセーフ
- シンプルにする
- 職務の分離
- Design for Failure
- 人は間違える
最新の情報も必要です。新しい脅威や攻撃手法はどんどん出てきます。同時に対抗する手段や新しいテクノロジーもどんどん出てきます。
セキュリティ対策として活用できるフレームワークはNIST CSFなどがあります。
あとは攻撃者の気持ち・AWSの特徴・便利なセキュリティ機能なども知っていると役に立ちます。
AWSの最新情報はJAWS-UGなどでも集められます。セキュリティに関してはSecurity-JAWSもどうぞ。AWSの各サービスUser Guideには「セキュリティ」ページがありこれも役に立ちます。あとはなんと言ってもググる力ですね。
敵を知り、己を知り、適切なセキュリティ対策を進めていきましょう。
ちなみに、このようなセキュリティの考え方を学ぶためのアプローチとして、私はIPAの情報処理安全確保支援士試験はバランスがいいと感じています。網羅的で原理原則と技術のバランスがいいですし、最新の情報も扱います。個人的にはこちらの教科書が試験を受けても受けなくても役に立ちます。私は試験に受かってからも繰り返し読んでいます。
AWSを使う意味
あと、AWSを利用する意味も理解しておく必要があります。AWSのメリットについて理解していますか？例えば以下のサイトがわかりやすいです。
俊敏性や柔軟性、マネージドサービスを活用してビジネスロジックに集中できるなど、なぜクラウドなのか？という意味を理解する必要があります。
2. [初級]AWSを始める、セキュアに
初めてAWSを始める場合、「AWSなんもわからんけど、とりあえずテキトーに始めてみるか」といった取り組み方をしてしまうケースがあります。
昔はいざ知らず、今はたくさん情報があります。AWSは包丁と同じで便利な道具にもなれば武器にもなります。扱いは気をつける必要があります。
例えばAWSを利用する上で遭遇する脅威には情報漏えいや多額の請求があります。
AWSは簡単に外部に公開できる基盤です。アクセス制御の設定や認証情報の管理が甘いと簡単に情報漏えいやアカウントの乗っ取りが起きます。閉じたローカルPCなどで試すのとはぜんぜん違うことを認識していないと、問題になります。
乗っ取られた後は決まって立てられるだけEC2が立てられてコインマイニングされます。以下の記事はGitHubへのクレデンシャルpushから10分で攻撃が始まった実際の攻撃者の動向が記録されています。
一方で、適切に使えばすごく安全に使えます。まずは「AWS利用開始時に最低限おさえておきたい10のこと」をチェックしましょう。
DevelopersIO 2021 Decadeでも「AWSアカウントを作ったら最初にやるべきこと 〜2021年版〜」という動画セッションがありますのでこちらもチェックしてください。
最初にやること(抜粋)
- IAMユーザーを作ってルートユーザーをMFAで封印
- 必要なサービス有効化
- CloudTrail
- Config
- GuardDuty
- Security Hub
- IAM Access Analyzer
- Detective
- Well-Architectedフレームワーク読む
AWSアカウントが作成されるときにメールアドレスとパスワードを登録しますが、このユーザーがルートユーザーです。ルートユーザーは権限が強く制限できないので、絶対に普段遣いしてはいけません。絶対だぞ！
代わりにIAMユーザーを作ります。ルートユーザーもIAMユーザーもMFAの設定を入れましょう。絶対だぞ。入れないと乗っ取られると思ったほうがいいでしょう。
あとは以下のブログ郡もチェックしてください。
Well-Architectedフレームワークは初心者も熟練者も読むドキュメントですが、以下の記事はどちらも利用できる万能の記事です。ここからWell-Architectedフレームワークに入門しましょう。
最初にやるべき・理解するべきことの情報はいっぱいあります。しっかりキャッチアップしながら始めましょう。
3. [初級]システム作る、セキュアに
初めてAWS上でシステムを構築する際に「AWSよくわからんけどオンプレとおんなじセキュリティ対策でええやろ」みたいな考えがあるかもしれません。原則は一緒ですがAWSの特性や便利になることを知る必要があります。
ざっくりとAWSにおけるシステム構築のセキュリティ的なメリットを上げると以下などがあります。
- すぐに調達可能なリソース(スケーラビリティ)
- マネージドサービスによる責任領域の低減
- リソース単位の詳細なアクセス制御(AWSレベル・ネットワークレベル)
- 簡単に利用可能なセキュリティ機能
- AWS WAF
- Cognito
- CloudFront
- などなど
責任共有モデル
AWSの基本的なセキュリティの考え方として責任共有モデルがあります。明確な責任範囲があります。
ただこれはサービス毎に違います。マネージドサービスと呼ばれる、特に下図右側の方にあるものはほとんどがAWS側で責任を持ちます。ユーザーが考えることが少なくなるため、これらは積極的に利用しましょう。
AWS 責任共有モデルを GxP ソリューションに適用する | Amazon Web Services ブログより引用
例えばオブジェクトストレージのS3は冗長化による可用性確保が管理されていたり、バージョニング・マルチリージョンへのレプリケーション・保管時の暗号化などが簡単に利用できます。利用しない手はありません。
マネージドサービスの活用でユーザーはビジネスロジックに集中できます。
一般的なセキュアWeb環境
以下のような構成が参考例です。
観点を箇条書します。
- 3層アーキテクチャ
- EC2はパブリックサブネットには設置しない
- なんならSSHさせない(SSM Session Manager利用)
- 上りの通信はNAT Gateway
- マルチAZ
- Auto Scaling
- ACMでHTTPS
- CloudFront + S3で静的コンテンツ配信、キャッシュ
- AWS WAF適用
最低限これくらいはやりましょう。以下で同じような構成の詳細解説しています。
以下各コンポーネント毎の考え方についてまとめていきます。
コンピューティング(EC2)
- EC2は直接パブリックに置かない(攻撃経路を無くす)
- OS/ミドルのパッチは常に最新に(脆弱性管理)
- SSHも可能な限りSession Managerを使う
- 最低限のポートだけ開ける
- ログを外部出力する(CloudWatchやS3)
- マルウェア対策する
- IAM Roleは最小権限に(SSRF対策)
- 可能ならIMDSv2を利用する
IMDSv2はOS/ミドル/アプリで対応が必要なので、必ず利用する必要はありません。ただ、外部入力を利用したHTTPアクセスを行うプロキシのような動作がある場合は必須です。(そもそもそういった機能はSSRFにつながるので極力無いほうがいいです)
最近はマルウェア対策として使えるCloud One Workload Securityが従量課金で非常に安く使えるようになったのでこれもおすすめです。
コンピューティング(コンテナ)
- 自前でDockerなどを動かさずにECS/EKSを利用する(管理部分の委任)
- AWSが管理している基盤のほうがセキュア
- Fargateを利用する(管理部分の委任)
- 信頼できるリポジトリを利用
- イメージをスキャンする(脆弱性管理)
- ログを外部出力する(awslogs/FireLens)
- NIST SP800-190もチェック
考え方はだいたいNIST SP800-190に書かれています。5つのリスク分類の中で、コンテナ内のリスクであるランタイムのセキュリティは特に対策難易度が高く、サードパーティの対策製品が高価であるため、まずはこれ以外の部分からやっていくといいでしょう。特にAWSでできる、管理レイヤーをAWSに任せたりECRイメージスキャンをすることは必須です。
コンピューティング(Lambda)
- 認証・認可されていないリクエストを受け付けない(アクセス制御)
- 外部からのリクエストを処理する場合はAPI Gatewayをフロントに入れる
- 強い権限のIAM Roleをアタッチしない(最小権限)
- 脆弱性のあるパッケージを利用しない(脆弱性管理)
- 実行数のクォータをモニタリングする(可用性)
LambdaのIAMも設定が緩いと攻撃者に利用されます。しっかり絞りましょう。外部公開は絶対にしないように。
ネットワーク
- 必要な単位でVPCを分割する(相乗りしない)
- Security Groupで詳細なアクセス制御する
- 最低限のポート
- 最低限の送信元
- Security Group ID指定での制御(無駄にIP指定しない)
- NACLでポリシー的なアクセス制御する
- VPC EndpointによるセキュアなAWSアクセス
古いけど以下は鉄板のブログ。
VPC Endpointを利用するメリットは以下にあります。
データベース
- RDS / DynamoDBなどマネージドなサービスを利用する(責任範囲)
- マルチAZ / リードレプリカによる冗長化
- バックアップによる復旧可能性
- TLSによる通信経路の暗号化
- IAMによる管理アクセスの制御
- ユーザー毎データアクセス権限の最小化
RDSはバックアップを自動で取得してくれます。適切に設定しましょう。あとバージョンアップはしっかりやりましょう。
DynamoDBは属性単位での制御もできるのでうまく利用しましょう。
ストレージ(S3)
- S3のアクセス制御機能の理解
- まずはパブリックアクセスブロック
- バケットポリシー / ACL
- バージョニング
- オブジェクトロック(WORM)
- クロスリージョンレプリケーション
- アクセスポイント(アクセス制御の分割)
- セキュリティベストプラクティス読む
- ユーザーアップロードがあるならスキャン
アクセス制御の手法が沢山あるので大変だと思いますが、めったに公開しないと思うので、公開しないものはすべてパブリックアクセスブロックで止めましょう。これを無効化する必要が出てきたら、バケットポリシーなどを学習します。
最近ではランサムウェア対策の1つとしてS3のバージョニングも有効であると紹介されたりします。重要な情報がある場合にはこのアプローチもありでしょう。
改ざんされたくないログなどはオブジェクトロック機能で書き換えできないようにします。
データレイクなどに利用するS3バケットは様々な利用者からのアクセスを制御する必要があるため、管理を簡単にするためにS3アクセスポイントを利用します。
S3に直接・間接的にユーザーからのオブジェクトを保存するならサーバーレスのマルウェアスキャン機能であるCloud One File Storage Securityがおすすめです。EC2を立ててスキャンする必要がありませんし、コスパもすごくいいです。
OS/ミドル
- とにかく脆弱性管理
- 脆弱性診断だけではない
- AWSならSSMインベントリ + Inspector + SSMパッチマネージャから始める
- より快適なのはFutureVulsなど1つの基盤で一連の脆弱性管理ができる仕組み
OS/ミドルに対する脆弱性管理はいわゆるCVEの管理です。AWSで提供されているInspectorなどから始めてもいいですが、FutureVulsはとにかく便利なのでおすすめしておきます。
アプリ
- アプリケーションセキュリティの責任はユーザー
- セキュアに実装してください
- 徳丸本読みましょう
- といっても大変なのでAWSの便利な機能を利用する
- 認証基盤としてCognitoが利用できると自前で実装しなくて済む
- Advanced Securityで認証強化
- アダプティブ認証(通常と違うログイン対策)
- 侵害された認証情報(漏洩したパスワード対策)
- AWS WAFを利用してフロントで攻撃を止められる
- 認証情報は埋め込まないでSSMパラメータストアやSecrets Managerに保管する
- 自動化された安全な仕組みでリリースする
モニタリング/ログ
- 現在の状態・過去の状態を確認することは必須
- 未来の状態も予測できる
- CloudWatchメトリクスから必要な情報を得る
- コンピューティングリソースの状態
- サービス・ビジネスメトリクス
- ログから詳細なインサイトを得る
- エラーなどを検知する
- 最新のCloudWatch機能を活用する
- 合成監視とか
お願いなので運用設計と運用監視をちゃんとやってください(切実)
見えていないと何もできません。便利なダッシュボードのサンプルもあるので使ってください。
以下のビジュアルモニタリングはWebアクセスしたスクリーンショットの差分をチェックする面白い機能です。
上記などの様々な監視系の仕組みを学べるワークショップがありますのでやりましょう。コンテナやサーバレスの監視も扱っています。
S3に保存したログはAthenaで確認します。だいたい日時でパスが切られているので以下を使うといいです。
自動化
CloudFormation使いましょう。Terraformなどでももちろんいいです。これらのツールは主に好みで使い分けます。あとはできる人がどれくらいいるか。アプリ寄りの自動化は最近はCDKが多いのでは？と思っています。
ここまで初級です
ちゃんと全部できていますか？全部初級ですからやりましょう。
各レイヤーで原理原則を守って、便利なサービスや機能を駆使して、快適なセキュリティ計画・実装・運用をしていきましょう。
AWSの仕組みはどんどん良くなるので、継続的にキャッチアップして適用し改善していきましょう。
4. [中級]AWSのセキュリティを維持する
使い始めや構築時のセキュリティについてはだいたいできてきました。
次の課題は「いまちゃんとAWS全体がセキュアな状態かわからん」みたいな段階です。AWSアカウントの全体できちんとセキュリティが確保できているか、確認していく必要があります。
全体を確認しようとすると人で行うのは大変です。そしてAWSはAPIですべての情報が取得できます。自動的にチェックできるのでそうしましょう。こういった全体のインサイトが得られることがクラウドのメリットの1つでもあります。
全体のセキュリティを維持する関連要素は以下の通り。
- AWS Config RulesによりAWSの状態を確認し、定義した状態から違反したらアラートを出せる
- アラートから自動修復も可能
- Security HubはConfig Rulesを利用したセキュリティチェックが可能
- 詳細なアクセス制御の維持にはIAM Access AnalyzerやPermissions Boundaryを利用する
セキュリティチェック手法については以下ブログで詳細に説明しているので参照してください。
Security Hubによるセキュリティチェック
上記内容から要点をいくつか説明します。
AWS Configは各AWSリソースの設定内容とその履歴を収集するサービスです。例えばSecurity GroupがいつSSHポートを開放したかなどが記録されています。
ConfigにはConfig Rulesという機能があり、この変更が定義したルールに従っているかをチェックし、違反したら通知ができます。そして、SSM Automation機能と連携することで自動で修復も可能です。SSHのポートが開放されたら自動で閉じることができます。
以下で実際にその動きを扱っています。
このConfig Rulesの仕組みはAWSのサービス内でも活用されていて、セキュリティチェックをまわしていく場合は以下を利用するとより楽になります。
- Conformance Packs
- Security Hub
両者長短はありますが、私としてはまずSecurity Hubから始めることを強く推奨します。以下のような観点からです。
- Security Hubはセキュリティチェック運用の理想形
- 直感的なスコア表示
- 無効化・例外の設定管理
- AWSが最新のベストプラクティスを適用
- 「AWS の基本的なセキュリティのベストプラクティスコントロール(AWS Foundational Security Best Practices)」のルールが優秀
- 現状30リソースタイプ・121種類のチェック
- 更新頻度が高い(リリースから約1年半で13回更新)
- 自動修復ソリューション
- マルチアカウントの集約
なので、「AWS環境全体のセキュリティをチェックしたい！」という場合にうってつけなのです。以下も参考になるので活用してください。
Security Hubの運用についてはいかに観点がまとめてあるので運用設計の参考にしてください。
マルチアカウントで集約することも可能です。
一方Conformance Packsを利用する場合は以下のような理由があります。
- サンプルテンプレートを活用したい
- ガリガリルールセットをカスタマイズしたい
- 自動修復も独自で設定したい
- カスタムルール(Lambda)を利用したい
まずSecurity Hubで実施し、習熟して拡張したことをやりたくなったらConformance Packsのような順序がいいと思います。
IAMのチェック
全体的なセキュリティチェックは各サービスの設定が危なくないかチェックできます。ただそれでも、アクセス制御の根幹であるIAMなどの詳細なポリシーについてはチェックできません。要件と大きく関わるためです。これは人で判断していく必要があります。
IAM RoleやS3バケットを始め、いくつかのリソースはリソースベースのポリシーがあり、ここでもアクセス制御ができます。特にこれらのポリシーが外部共有できるようになっている場合には、必ずチェックが必要です。それを助けてくれるのがIAM Access Analyzerです。
IAM Access Analyzerは以下のリソースのポリシーをチェックし、外部共有しているものがあればリストアップしてくれます。
- S3バケット
- IAM Role
- KMSキー
- Lambda関数
- SQSキュー
- Secrets Managerシークレット
イメージとしては以下のようになります。
この通知を受けて、設計通りのものなのか、そうではないのかをレビューしていくことで、今起きている状況を確認し対応していくことが可能です。もちろん、設定変更前の事前の確認も必要ですけどね。詳細は以下のブログを参照してください。
IAMの権限昇格対策
AWSの利用が進むと開発者がIAMの権限を持つ場合があります。特にEC2やLambdaなどのリソースにアタッチするIAM Roleを設定するためです。これは開発速度の向上には必要ですが、同時にリスクになります。
IAM作成の権限を渡しつつ、必要以上の権限の行使や権限昇格を防ぐ手段としてPermissions Boundaryがあります。
IAM エンティティのアクセス許可の境界 - AWS Identity and Access Managementより引用
Permissions BoundaryはIAM UserやIAM Roleにアタッチされたアイデンティティベースのポリシーに加えて、Permissions Boundaryで設定したポリシー権限しか許可されないというポリシーの境界線(ガードレール)です。
この機能の最大の特徴は、作成するIAMリソースに対してもPermissions Boundaryを強制させることができる点にあります。
Permission Boundaries How to Truly Delegate Permissions on AWSより引用
まず管理者は開発者用とLambda用のPermission Boundaryを用意します。
開発者にアタッチするBoundaryの中で、「作成するIAM RoleにはLambda用のPermission Boundaryをアタッチすること」を条件としておきます。
すると、作成されるIAM RoleにもPermission Boundaryをつけなければならなくなるので、これに対してもガードレールが適用されます。ここにIAM関係の操作を禁止するポリシーを記述すればオッケイです。
うまいこと開発者に自由を渡しつつ、やってはいけないことだけ仕組みで絞ることができます。実際の使用例は以下にもあります。
セキュリティを維持していくまとめ
自動で動くセキュリティチェックを駆使しましょう。人で全数チェックはできませんし、すでに効率のいい仕組みがあります。そしてアラートを受け取ったり自動で修復するようにして運用を高速に楽に回しましょう。人手ではなく自動の仕組みで対処するところがミソです。
5. [中級]インシデントに対応する
これは非常に多い課題ですが「攻撃されているかわからん。気づいても対処の仕方がわからん。」というケースがあります。
なんとなくイメージで「よくわからん」となっていることも多いと思います。でもそんなに難しくありません。何が起きるのか？というところから確認していくといいです。
AWSでのインシデント検知と対応にはAmazon GuardDutyとAmazon Detectiveが利用できます。GuardDutyでは例えば以下のような脅威が検知できます。
- EC2でコインマイニング
- IAM不正利用
- S3への不審なアクセス
Amazon Detectiveは自動でログを関連付けしてくれて調査が簡単になります。
それぞれ確認や対処の方法は、User Guideにめちゃくちゃわかりやすく書いてあります。この便利なセキュリティ対応サービスを使っていくことで簡単に対応できます。
これらの使い方を詳細に解説します。
インシデント対応の心構え
Security Hubなどを利用することで、インシデントが起きないように予防・防止することが可能です。しかし、いくら頑張ってもインシデントが起きるときには起きます。
予防も大事ですが、なにか起きた後迅速に対応することも同じように大事です。
これはNISTのCSF(サイバーセキュリティフレームワーク)では検知・対応・復旧になります。もう少しこれを深堀りして説明します。
CSFでは5つのコア機能があります。下図にはそれが適用されています。左から識別・防御・検知・対応・復旧です。一部ですが、それぞれの機能にAWSのサービスを割り当てた図です。
各コア機能にはサブカテゴリがあり、これを活用して自身の環境のセキュリティ対策のカバレッジを確認できます。他にも活用方法は色々ありますが詳しくはAWSがリリースしているNIST CSFの資料をご確認ください。
上記図の右上、対応・復旧にそれぞれ計画の作成があります。
ちゃんと計画できていますか？
計画を立てるには、まずどんなインシデントが起きるか知らないといけませんよね。そこから始めましょう。
脅威検知の仕組みと内容
Amazon GuardDutyはAWSのマネージドな脅威検知サービスです。
通常、脅威を検知するには各種ログを収集し、不審なIPリストや異常な行動パターンなどと突き合わせて判断します。
GuardDutyはAPIの実行履歴であるCloudTrail、VPC内のトラフィックログであるVPC Flow Logs、VPC内のDNSクエリログであるDNS Logsをバックグラウンドで自動収集します。そしてパートナーセキュリティ企業などと共有されている不正に利用されているIPリストやDNSドメインなどの脅威インテリジェンスや、攻撃者の行動パターン、機械学習によるパターンと突き合わせて、異常をインテリジェントに検知します。
これがポチッと有効化して、それだけで全部できます。使わない手はありませんね。
具体的な検知内容も把握しましょう。大きく3種類あると考えると簡単に見えませんか？以下になります。
- IAMタイプ
- EC2タイプ
- S3タイプ
IAMタイプは、不正なログインやCloudTrail無効化などの操作を検知。EC2タイプはコインマイニングやマルウェア感染によるC&Cサーバとの通信などを検知。S3タイプは不審な公開設定の変更やTorアクセスなどの検知です。
これらの脅威はすべてUser Guideに記述されています。ガイドには、検知名・概要・判断する内容・推奨の対応方法が書かれています。いざとなったらこれを頼れます。
すべての検知内容と対応方法を確認するのは大変ですが、これらは3種類の検知タイプ毎にだいたい同じと思っていいです。以下のようになります。
- IAMタイプ
- 認証情報を無効化する
- EC2タイプ
- EC2を隔離、保全、調査する
- 調査は得意な会社に依頼できる準備でもいい
- S3タイプ
- アクセス権限を絞る
それぞれ詳細に説明します。
脅威検知時の初動対応
IAMタイプは不正に利用されているIAMクレデンシャルを無効化することから始めます。クレデンシャルはIAM Userであればアクセスキーで、IAM Roleであれば一時的なセッションになります。
IAM Userのアクセスキー無効化はそのままなので割愛します。必要に応じて削除でもいいでしょう。
IAM Roleの場合一時的なセッションなので、削除するものがないように思われるかもしれません。しかし無効化は可能です。IAM Role詳細画面の「セッションの無効化」タブからこの操作が可能です。仕組みとしてはCondition(条件)にボタンを押した時刻以前のセッションをDenyするポリシーが追加されます。
IAMクレデンシャルを無効化できたら一旦封じ込め完了です。以降はCloudTrailを確認しながら影響範囲を確認したり、クレデンシャル漏洩経路の特定です。
EC2タイプはまず隔離です。Security Groupを変更します。in/outのルールをすべて削除すれば、通信の許可されないSecurity Groupになるのでこれに置き換えて、他のSecurity Groupは全て外します。続いてAMIバックアップを再起動無しで取得します。いっしょにECSスナップショットが取れますのでストレージのバックアップにもなります。再起動しないのは、隔離したインスタンスのメモリを保持するためです。ここまでで一旦大丈夫です。
この後はEC2を調査していきます。しかしこれは、安易に手出ししてはいけません。うかつな操作は証跡を無くすことにも繋がりかねません。少なくとも専門家に依頼するフローだけでも計画に入れておきましょう。
もしこのあたりをやっていきたいと思うのであれば、セキュリティ会社が書いている以下のEC2フォレンジックの記事が参考になるでしょう。
S3タイプはバケットのアクセス制御を絞っていきます。S3はアクセス制御の機能がたくさんあり覚えるのが大変です。しかしながら外部公開を止める、ということであればパブリックアクセスブロックの機能をすべてオンにするだけで達成できます。バケット詳細の「アクセス許可」で編集からオンにすればOKです。
S3の調査にはCloudTrailデータログが必要になります。CloudTrailではデフォルトで管理ログのみ取得されてデータログは追加の設定と追加の費用が必要になります。重要なデータがある場合はこれも有効化しておくといいでしょう。最近バケット単位での有効化が可能になりました。コスパよく利用できます。
以上のようなGuardDutyの使い方や運用方法については以下にもまとめていますのでご確認ください。
他にも、インシデント対応の計画として以下のような観点があります。
- エスカレーションフローなども決めておこう
- 誰がいつまでにどこまで判断するか
- 必要なログは収集しておこう
- インシデント検知のアラートと一緒に目につくように対応することを出そう
- いざという時は対応漏れが起きやすいのでチェックリストなどで簡単に実行できるようにしよう
- 予行練習たくさんやろう
こういった計画などは、少し観点が違いますが弊社の運用チームがやっていることも参考になるのでいくつか載せておきます。
クラスメソッドでAWS障害検知から30分でやったこと
- AWS公式確認(SHD)、マニュアルに従い対応開始
- 社内slackチャンネル作成
- 体制構築、情報収集、顧客向け文面作成、レビュー
- 顧客向けポータルに情報を掲載
- 顧客向けにメール送信完了
今後も継続してサポート品質上げていきます!! #aws障害— Jun Chiba (@iron_breaker) October 22, 2020
インシデント対応まとめ
長めに細かく書きましたが、もう一度整理すると3種類の対応を計画するところから始めればいい、ということです。何が起き、どうすればいいかを把握できていれば難しくないと思えるのではないでしょうか？
ぜひGuardDutyを有効化し、運用を検討してみてください。
詳細な調査が必要なケース
GuardDutyは非常に優秀な脅威検知の仕組みですが、得られる情報は全てではありません。封じ込めをした後の調査では複雑な関連性を辿りながら事象の原因を辿る必要が出てくるかもしれません。
例えば攻撃の主体となったIAM Userは別のIAMから作成されているかもしれません。EC2も隣のEC2からやられているかもしれません。
辿るには圧倒的にログが必要です。
残念ながらGuardDutyの仕組みは自動でログを収集して検知してくれますが、ログ自体を利用者に提供するものではありません。別途ログを確認する必要があります。
CloudTrailのログはS3に保存しているので、Amazon Athenaでクエリをかけながら必要なものを取得します。ただログの調査は色々大変です。例えば以下のように。
- ノイズが多い
- ちょうどいいログクエリを探すのに一苦労
- 関連性を見出しづらい
- クエリではなく、あらかた絞った状態でエクセルで検索を駆使したり目grepしてがんばる
- 動的な範囲の集計やりづらい
- この時間範囲のこのユーザーの実行API数とか、ぐりぐり動かしながらやりたい
- 異常値を見つけにくい
- どの観点で分析したらいいかわからん
というわけで、この調査を簡単にするサービスとしてAmazon Detectiveが活用できます。
Detectiveによる調査
Detectiveはインシデント調査のサービスです。
GuardDutyと同じようにCloudTrail / VPC Flow Logs、そしてGuardDutyのFindingsも取り込んでログを処理し、関連付けと可視化をしてくれます。これによりこれが…
こうなるんじゃ！
調査部分で各種ログや分析ツールを利用してたところがDetectiveでできます！
Detectiveは内部にグラフDBを利用し、各リソースとの関連付けを解決してくれます。これ人がログでやると大変ですが、それが得意なグラフDBを使っているところがDetectiveの素晴らしいところです。脅威の原因や影響範囲を辿るのが捗ります。
実際の画面を見てみます。以下はS3バケットの情報です。どのIAMから作成されたか出てきます。これはIAM Userなどでも同じです。EC2ならアタッチしているIAM Roleなども紐付いていて、クリックすればそちらの調査画面に遷移します。
S3のページの下の方です。関連するAPIイベントもいっしょにまとめられています。送信元IPやAWSサービス別・リソース別にAPIがまとめられていて、更にAPIの種類などでフィルタリングできます。以下では関連するPut系(変更系)のAPIについて絞り込んでいます。モザイクを掛けていますが、ツリーの元がIPアドレスになっていて、これもページ遷移でたどれます。
以下はEC2について関連するAPI実行履歴をGeoIPでマップに載せたものです。直感的に怪しいIPやそれに関連したAPIを見つけることが可能です。
このようにGuardDutyで検知した内容から各種リソースをぐりぐり辿って調査できます。以下でも動画で実際の画面を使いながらこのあたりを解説していますので合わせて見てください。
Detectiveを使うと調査が非常に捗ります。しかしこちらでもログを出力できるわけではありません。最終的にログをみることも必要になる場合があります。ログを見る仕組みとしてSIEM(Security Information and Event Management)を利用することも検討しましょう。
SIEMによるログ分析
AWSと親和性のあるSIEMソリューションはいくつかありますが、最近OSSで出てきたAmazon OpenSearch Serviceを利用したSIEM on Amazon OpenSearch Serviceがあります。こんな感じです。
これはCloudTrailの可視化ダッシュボードでデフォルトでこの状態です。ログインの失敗やルートユーザーのログイン、API失敗や実行しているAPIの円グラフなど、分析する観点に沿った可視化がされていて、そこから必要なログにアクセスが可能です。以下のログに対応しています。
- セキュリティ、ID、およびコンプライアンス
- Amazon GuardDuty
- GuardDuty findings
- AWS Directory Service
- Microsoft AD
- AWS WAF
- AWS WAF Web ACL traffic information
- AWS WAF Classic Web ACL traffic information
- AWS Security Hub
- Security Hub findings
- GuardDuty findings
- Amazon Macie findings
- Amazon Inspector findings
- AWS IAM Access Analyzer findings
- AWS Network Firewall
- Flow logs
- Alert logs
- Amazon GuardDuty
- 管理とガバナンス
- AWS CloudTrail
- CloudTrail Log Event
- CloudTrail Insight Event
- AWS CloudTrail
- ネットワーキングとコンテンツ配信
- Amazon CloudFront
- Standard access log
- Real-time log
- Amazon Route 53 Resolver
- VPC DNS query log
- Amazon Virtual Private Cloud (Amazon VPC)
- VPC Flow Logs (Version5)
- Elastic Load Balancing
- Application Load Balancer access logs
- Network Load Balancer access logs
- Classic Load Balancer access logs
- Amazon CloudFront
- ストレージ
- Amazon FSx for Windows File Server
- audit log
- Amazon Simple Storage Service (Amazon S3)
- access log
- Amazon FSx for Windows File Server
- データベース
- Amazon Relational Database Service (Amazon RDS)(Experimental Support)
- Amazon Aurora(MySQL)
- Amazon Aurora(PostgreSQL)
- Amazon RDS for MariaDB
- Amazon RDS for MySQL
- Amazon RDS for PostgreSQL
- Amazon Relational Database Service (Amazon RDS)(Experimental Support)
- 分析
- Amazon Managed Streaming for Apache Kafka (Amazon MSK)
- Broker log
- Amazon Managed Streaming for Apache Kafka (Amazon MSK)
- コンピューティング
- Linux OS via CloudWatch Logs
- /var/log/messages
- /var/log/secure
- Linux OS via CloudWatch Logs
- コンピューティング
- Windows Server 2012/2016/2019 via CloudWatch Logs
- System event log
- Security event log
- Windows Server 2012/2016/2019 via CloudWatch Logs
- コンテナ
- Amazon Elastic Container Service (Amazon ECS) via FireLens
- Framework only
- Amazon Elastic Container Service (Amazon ECS) via FireLens
- エンドユーザーコンピューティング
- Amazon WorkSpaces
- Event log
- Inventory
- Amazon WorkSpaces
構成は以下のようになっていて、S3バケットにログを集めれば自動的にETL処理されてOpenSearchに取り込まれます。
SIEM on Amazon OSSの運用例としてfreee株式会社さんの登壇したものも以下にありますので参考にどうぞ。
Radwareによる調査
Detectiveも非常に優秀ですが、サードパーティのインシデント調査製品としてRadwareがあります。以下のようにインシデントを時系列 + 関連付けして表示してくれます。一発で原因である最初のイベントまで辿れます。
こちらも紹介ブログを載せておきます。
インシデントに対応する まとめ
どんなインシデントが起こるか知り準備・計画します。人力・目grepは辛いのでインテリジェントなサービスを活用しましょう！
6. [上級]組織全体でガバナンスを効かせる
AWSの利用が拡大してくると、「AWSアカウントやAWS利用者が増えて管理が行き届かない」という課題がでてきます。
利用が広がったAWS環境全体の管理には、ここまでの応用で対応できます。
自動化された仕組みを利用してセキュリティチェックを全体に回していきましょう。仕組みの展開にはCloudFormationなどを利用した自動化が必須です。
そしてこういったセキュリティチェックの詳細な基準や、必要なログ出力やセキュアなパラメータなどを整えてガイドラインを整備していきます。
加えて、各種AWSのマネジメント&ガバナンスサービスで全体管理が捗ります。
AWSアカウントの集約管理
集約管理する機能として以下を紹介します。
- AWS Organizations
- CloudFormation StackSets
- AWS SSO
- AWS Control Tower
AWS Organizationsは複数のAWSアカウントを束ねて管理する仕組みです。
AWS Organizations の用語と概念 - AWS Organizationsより引用
AWS Organizationsは所属するメンバーのAWSアカウントをOrganizationsUnit(OU)にまとめて整理できます。そしてService Control Policy(SCP)により強力なアクセス制御が可能です。
SCPはAWSアカウント全体に適用されるポリシーで、IAMポリシーと同じように記述します。例えば以下のようなポリシーがよく使われます。
- 特定リージョン使用禁止
- CloudTrail無効化禁止
- GuardDuty無効化禁止
- S3バケット公開禁止
- タグのないリソース作成禁止
参考になるポリシーはUser Guideにあります。開発環境 / 本番環境 / 共用環境などで使い分けて適用します。
AWS Organizationsについては以下のブログもどうぞ。
AWS Organizationsは以下のような各種AWSサービスと連携して、マルチアカウント管理の機能を発揮します。
- AWS SSO
- CloudFormation StackSets
- GuardDuty
- Security Hub
- Systems Manager
- CloudTrail
- Config
- などなど
AWS Systems ManagerではExplorer機能を利用することで、すべてのAWSアカウントのEC2情報をダッシュボードにまとめて管理が可能です。
マルチアカウントへの仕組みの展開
仕組みの展開にはCloudFormationのStackSets機能が利用できます。StackSetsはマルチアカウント・マルチリージョンへのスタックの展開が可能です。
StackSetsのいいところは、AWS Organizationsと連携しても、連携しなくても利用できることです。AWS Organizationsを利用できない環境でもStackSetsでマルチアカウントの自動化が可能です。
他にも、以下はAWS SummitでVisional様が紹介していたTerraformによるマルチアカウント管理の手法です。
上記はかなり作り込んでいる例ですのでハードルが高く感じらるかもしれません。どのような自動化ツールでもいいですが、最初からすべてを作り込むことはできません。地道に必要なところからやっていけば大丈夫です。
ID集約
AWS SSOはシングルサインオンの仕組みです。各AWSアカウントへのアクセスを集約して管理できます。AWS Organizationsと連携することで利用できます。既存のADなどと連携も可能です。
AWS Single Sign-On 紹介 | Amazon Web Services ブログ
以下も参考になります。
AWS Organizationsが利用できない場合でもID集約自体は可能です。1つのAWSアカウントにIAM Userを集約し、各AWSアカウントにIAM Roleを利用してスイッチロールする方法です。従来からある手法でいわゆるJumpアカウントと呼ばれる手法です。
AWS SSOとJumpアカウント方式の一番の違いは、認可を集約できるかどうかです。AWS SSOは各アカウントにアクセスするための権限を権限セットとしてAWS SSO側で管理できます。一方でJumpアカウント方式は各アカウントのIAM Roleでアクセス制御するため、認証と認可が別々の管理になります。AWS SSOが選択できる場合はこちらを利用するほうが管理は集約できます。
もちろんこれ以外に、SAMLなどを利用して別の基盤で集約管理してもいいでしょう。
AWS Control Towerによる統制管理
AWS Control TowerはAWSのマルチアカウント管理のベストプラクティスに従ったガードレールを展開します。以下のような構成になります。
構成要素は以下のようになっています。
- 管理アカウント
- AWS Organizationsのマネジメントアカウント
- AWS SSO管理
- ログアーカイブアカウント
- CloudTrail / Configログ集約
- Auditアカウント
- Configセキュリティ通知集約
- ユーザーアカウント
- 各利用者アカウント
これにより以下の機能を展開できます。
- ID管理
- AWS SSOと連携した認証認可の集約
- ガードレール
- SCPやConfig Rulesにより違反を防止・検知
- ベースライン展開
- CloudTrailやConfigなど一律で展開
- ログ管理・監視
- Log Archiveアカウントにログ集約
- Auditアカウントにアラート集約
詳細は以下の記事を参考にしてください。
AWS Control Towerタグの記事一覧も一緒にどうぞ。
ガバナンスを効かせる組織づくり
ガバナンスを効かせる仕組みはAWSの機能だけではありません。
AWSの利活用には組織の体制や仕組みづくりも必要です。
CCoEを立ち上げる企業も多いです。CCoE(Cloud Center of Excellence)はクラウド推進の組織です。組織により形は様々で、バーチャル組織として部門横断で活動することもあれば、情シスからの派生やDX推進チームが担うこともあります。共通して言えるのはクラウドのスピードに合わせて変わっていく組織です。
1つの参考例として塩野義製薬様の事例を載せておきます。
役割としては以下のようなものがあります。
- ガイドライン整備
- トレーニング提供
- 勉強会主催
- 共通インフラ整備
- 全体管理
- セキュリティ運用
- などなど
様々な役割の人が集まることが大切です。
AWSと各部門
AWSを直接構築・利用する部門だけがAWS利用者ではありません。
セキュリティ部門、調達部門、監査部門など様々な部門も同様にAWSに関わります。そして、アカウントの払い出しを自動化したり、各種仕組みの展開やセキュリティチェック・監査の自動化で効率よく仕事ができます。
せっかく人力ではなく自動化できる仕組みがあるので、活用しない手はありません。これもBuilderの役割になります。すべての人がBuilderなのです。
特にクラウドの監査についてはCloud Audit Academyというコンテンツがあります。監査人がどのようにしてAWSを監査するか学習できるコンテンツです。もし、煩雑な管理のエクセルによるチェックシートで疲弊している方がいたら、ぜひこのコンテンツを使って監査を効率化しましょう。
AWSに関わる人みんなBuilderです。
組織全体でガバナンスを効かせる まとめ
全体管理の仕組みを活用しつつ、AWSの機能だけではない、クラウドの恩恵を受ける組織の形で効率よく全体管理しましょう。
まとめ
- 変わらないセキュリティの考え方を身につける
- AWSのメリットと基本を押さえる
- 便利なサービスを活用する
- とにかく自動化
- 組織で最適化する
- 全員Builderで全員セキュリティ担当だ
いかがでしたか？これらの情報が皆さんの役に立てば幸いです。
そして、ガンガンインプットして、ガンガン活用して、成果を是非アウトプットしてください。周りの方は高度な技術的知識だけではなく実体験とその辛さも知りたいと思っています。その体験は簡単に得られない貴重なものです。私も是非知りたいのでこのブログを見た方は実践してアウトプットしてください！
12
