Go to Qiita Advent Calendar 2024 Top
LoginSignup
20
16

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

@dcm_chida(Takuya CHIDA)

AWSセキュリティ・サバイバルガイド2020

Posted at

はじめに

こんにちは。@dcm_chidaです。
在宅勤務もついに2ヶ月目に突入しました。朝はコーヒー、夜はビールの毎日です。

そんなある日の業務後、社内チャットにて突然こんな報告が…

後輩社員💁‍♂️ > 在宅勤務でアレ1だったので、先程Qiitaに記事を投稿しました。

ムムッ！なかなかやりおる…　これは負けてられん！

というわけで「在宅勤務でアレだったのでカレンダー」２日目でございます。

やったこと

  • NISTのセキュリティフレームワークに沿ってAWSセキュリティTODOリストを考えてみた
  • AWSマネージドサービスを駆使して防御 → 検知 → 対応 の処理フローを設計する

対象とする人

  • AWSチョットワカル人（基本的な用語がわかればヨシ！）
  • セキュリティの雰囲気を何となく理解したい人
  • 在宅勤務でアレな人

AWSセキュリティの第一歩

よし、じゃあ早速セキュリティ対策していくぞぉぉーー！

…と言いたいところですが、何の根拠もなく手当たり次第にオレオレ対策をしていくのはよくないです。どこかで設定の抜け漏れが発生してしまう可能性があります。

こういう時は何かのフレームワークに基づいて対策を考えるのがベターです。

AWSでは2019年1月に「NIST サイバーセキュリティフレームワーク (CSF): AWS クラウドにおける NIST CSF への準拠」というホワイトペーパーを発表しています。これを読みましょう。

aws-csf.png

NISTは米国の歴史ある研究機関であり、情報セキュリティに関する様々なガイドラインや管理策などを作成しています。NISTサイバーセキュリティフレームワークもその一つです。

CSFでは下記５つの機能を中心として、実施すべき重点対策をまとめています。2

機能 内容
Identify（識別） 組織としてのセキュリティポリシー策定、リスク評価・管理など
Protect（防御） アクセス制御、データ暗号化など
Detect（検知） モニタリング、異常検知など
Respond（対応） 被害最小化、原因分析など
Recover（復旧） 再発防止、復旧方法など

AWSのセキュリティのブログや発表資料などをみると、このフレームワークに沿って説明しているモノがあります。特にセキュリティオートメーションの文脈ではよく出てきます。

image.png
Introduction to AWS Security Hub (SEC397) - AWS re:Invent 2018 より抜粋

このフレームワークの大きな特徴は「インシデントを未然に防ぐためにどうすべきか（事前対応）」だけでなく、「インシデントが発生した後にどうすべきか（事後対応）」まで考慮されているという点です。

もちろん未然に防ぐことが出来るならそれが一番いいのですが、

AWSでは新機能が毎週のようにリリースされるし…
リソースや設定は流動的に変更されるし…
多くのOSSやサービスが複雑に関わり合って構成されているし…

セキュリティインシデントを100%防ぐなんて、(AWS完全に理解したという超人でもなければ）誰にも保証できません。

ならばっ!!
インシデントが発生すると想定して対策を打つまでっ!!

…という心意気が大事です。

それではこのフレームワークをベースにしてAWSのセキュリティ対策をまとめていきます。

AWSセキュリティ・サバイバルガイド2020

本記事でこれから紹介していく項目を先にリストアップしておきます。

【識別】
    ✔️ アカウント登録情報の最新化
    ✔️ 予算の設定
    ✔️ Configの有効化
【防御】
    ✔️ IAMアクセスアナライザーの有効化
【検知】
    ✔️ GuardDutyの有効化
    ✔️ SecurityHubの有効化
【対応】
    ✔️ Detectiveの有効化
【復旧】
    ✔️ バックアップの取得設定

こんな感じ↓のパイプラインをイメージしてください。

aws-security-flow.png

※ CloudTrailやCloudWatch Eventの設定は既に設定している前提です。

もちろんこれで完璧とはなりません。

ここで紹介するのは必要最低限なセキュリティ対策です。実装や設計に依存する物（コンテナやアプリケーションレベルの対策）は今回は扱いません。AWSではCloudWatchLogsやWAFなどセキュリティ関連のサービスはたくさんあるので、自分のアカウントの利用目的に応じて対策方法を拡充してください。

最近のAWSのセキュリティサービスはSecurityHubを基点にしていく傾向があります。

実際、DetectiveやIAMアクセスアナライザーは去年末に発表されたばかりのサービスです。特にDetectiveは大きなアップデートです。これで防御→検知→分析というフローが構築できます。今後出てくる新しいサービスもSecurityHubに統合される可能性が高いでしょう。

このようにSecurityHubを中心としてセキュリティ対策を講じていけば、自ずとNISTのフレームワークに沿っていくはず。



AWSのセキュリティを雰囲気で理解しているみなさん。いいですか。

パブリッククラウドが当たり前となった今、AWSは攻撃者の格好のターゲットとなっています。

このAWSという戦場で生き抜くためにやるべきことはただ一つ。

SecurityHubという防衛拠点を設立し、セキュリティの指揮・統制経路を確保するのです！！



それではNISTのCAFの5機能に沿ってポイントをおさえていきます。

識別 (Identify)

  • 資産管理（ID.AM）
    • 組織のビジネス目的達成を可能にするデータ、要員、デバイス、システム、施設を、ビジネス上の目標および組織のリスク戦略から見た相対的な重要度と矛盾しない形で識別し、管理します。
  • ビジネス環境（ID.BE）
    • 組織の使命、目標、利害関係者、アクティビティを理解し、優先順位を設定します。この情報は、サイバーセキュリティの役割、責任範囲、リスク管理上の意思決定を通知するために使用します。
  • ガバナンス（ID.GV）
    • 組織の規制上の要求事項、法的要求事項、リスク上の要求事項、環境上の要求事項、運用上の要求事項が理解されているかどうかを管理および監視し、サイバーセキュリティリスクをシニアマネジメント層に通知するための方針、手順、プロセスです。
  • リスク評価（ID.RA）
    • 組織の運営(使命、機能、イメージ、社会的評価を含む)、組織の資産、個人に対するサイバーセキュリティリスクを組織が把握することです。
  • リスク管理戦略（ID.RM）
    • 組織の優先順位、制約、リスク許容度、前提を明確化し、運用リスクに関する意思決定の裏付けとして利用します。
  • サプライチェーンリスク管理（ID.SC）
    • 組織の優先順位、制約、リスク許容度、前提を明確化し、サプライチェーンリスクの管理に関する意思決定の裏付けとして利用します。組織は、サプライチェーンリスクを識別、評価、管理するためのプロセスを確立し、導入しています。

https://d1.awsstatic.com/whitepapers/compliance/JP_Whitepapers/NIST_Cybersecurity_Framework_CSF_JP.pdf

■ アカウント登録情報の最新化

全てのアカウントで実施すべきなのがアカウント登録情報の最新化です。

今の時代、もはやパブリッククラウドは当然のものとして定着しています。
そうなると「AWS、もうだいぶ長いこと使ってるなぁ〜いつから使ってるんだっけ？:rolling_eyes:」という方がソコソコいるはずです。

ちょっとWait！

前任者からアカウントを引き継いだけど、メールアドレスが古いまま放置されている！

そういえば最初AWSとかよくわからなかったから、適当に捨てアドで登録したような気がする！

なんてことありませんか？

いざインシデントが発生した場合、AWS側からのアラートは登録してあるメールアドレスに飛んできます。もしメールアドレスが有効でないと、この第一報に気づくことが出来ません。個人で使っている方も「普段使ってないアドレスで登録してた」ということのないように再確認しましょう。

アカウント情報はルートユーザーでログイン後右上の「マイアカウント」の項目から確認可能です。

identify2.png

■ Configの有効化

AWS ConfigはEC2インスタンスやIAMユーザなどのAWSリソースの設定や変更を記録できるサービスです。あらかじめルールを設定して、それに違反しているかどうかをチェックすることが可能です。AWS提供のマネージドルールやLambda関数で自作したカスタムルールなどが利用可能です。マネージドルールは83個もあってかなり多いのですが、全てを有効化する必要はありません。3

AWS Config マネージドルールのリスト - AWS Config

オススメルールを抜粋しておきます。

ルール名称 内容
cloudtrail-enabled CloudTrailが有効になっているかどうか
vpc-flow-logs-enabled - AWS Config VPCフローログが有効化されているかどうか
guardduty-enabled-centralized GuardDutyが有効化されているかどうか
root-account-mfa-enabled ルートユーザーのMFAが有効化されているか
iam-root-access-key-check ルートユーザーアクセスキーが生成されていないか
s3-account-level-public-access-blocks アカウントレベルでS3のパブリックアクセスがブロックされているか
desired-instance-type EC2インスタンスのタイプが指定したものであるか
restricted-ssh - AWS Config SSH通信がセキュリティグループでIPアドレス制限されているかどうか

SNSトピックの設定も出来ます。予めセキュリティ関連の通知用のSNSトピックを作成しておくと、他でも使い回しができて便利です。

■ 予算の設定

AWSセキュリティ対策として意外に有効なのがコストを監視することです。

インスタンスが乗っ取られてGPUインスタンスで仮想通貨マイニングされた！
重要なDBが全部削除されている！

こういう場合、コストを監視していれば一撃です。

AWS Budgetsという機能で予算管理ができるので有効化しておきましょう。ダッシュボードの作成やアラートなども設定可能です。

budget.png

※5~6月でコストが急騰していますが、これは諸事情によりGPUインスタンスをぶん回しまくった結果によるものです。攻撃ではありません。

防御 (Protect)

  • アイデンティティ管理とアクセス制御（PR.AC）
    • 物理的な資産と論理的な資産、関連施設にアクセスできるのは正当な権限のあるユーザー、プロセス、デバイスのみに限定され、正当な権限のあるアクティビティやトランザクションへの不正アクセスに関して想定されている、評価済みのリスクに矛盾しない形で管理されている。
  • 意識向上およびトレーニング（PR.AT）
    • 組織の要員およびパートナーに対して、サイバーセキュリティに関する意識教育が提供され、関連する方針、手順、取り決めに従ってサイバーセキュリティ関連の義務および責任を果たすためのトレーニングが実施されている。
  • データセキュリティ（PR.DS）
    • 情報およびレコード (データ) が組織のリスク戦略に従って管理され、情報の機密性、完全性、可用性が保護されている。
  • 情報を保護するためのプロセスおよび手順（PR.IP）
    • セキュリティ方針 (目的、範囲、役割、責任、経営者のコミットメント、組織間の連携を取り扱ったもの)、プロセス、手順が維持管理され、情報システムと資産の保護を管理するために利用されている。
  • 保守（PR.MA）
    • 工業用制御システムと情報システムを構成している要素の保守および修理が、方針および手順に従って実施されている。
  • 保護技術（PR.PT）
    • システムと資産のセキュリティおよびレジリエンスを確保するために、関連する方針、手順、取り決めに従って技術的なセキュリティソリューションが管理されている。

■ IAMアクセスアナライザーの利用

これはオススメなので必ず有効化しましょう。お金もほとんどかかりません。

IAMアクセスアナライザーを導入すれば、S3やIAMロールなどのポリシーをチェックして、外部からアクセス可能かどうかを検知してくれます。もし意図しない公開設定や権限付与があれば、検知結果からすぐに確認可能です。

ここら辺のポリシーチェックは人間のやる作業ではないので、こうしたツールが提供されるのは非常にありがたいです。S3の部分だけを切り出したS3アクセスアナライザーというものもあります。

AWS Identity and Access Management (IAM) Access Analyzer を使った意図しないリソースアクセスの特定 | Amazon Web Services ブログ

protect-iam.png

検知 (Detect)

  • 異常とイベント（DE.AE）
    • 異常なアクティビティを的確なタイミングで検知し、当該のイベントが及ぼす潜在的な影響を把握する。
  • セキュリティの継続的なモニタリング（DE.CM）
    • 情報システムと情報資産を別個の間隔で監視して、サイバーセキュリティイベントを洗い出し、保護手段の有効性を検証する。
  • 検知プロセス（DE.DP）
    • 異常なイベントがタイムリーかつ適切に認識されるように、検知のプロセスおよび手順を維持管理し、検査する。

検知のフェーズではGuardDutyとSecurityHubの二つが鉄強コンボです。どちらも有効化しておきましょう。

■ GuardDutyの有効化

GuardDutyはCloudTrail/VPCフローログ/DNSクエリログなどのログを対象に自動的に脅威を検出するサービスです。

CloudTrailなどのログ収集設定は事前に設定しておく必要があります。
※GuardDuty自体を有効化してもその他のログ機能が有効化されるわけではありません！

不審なコンソールログイン4やポートスキャンなどを検知してくれます。

guardduty-sample.png

■ SecurityHubの有効化

SecuirtyHubではセキュリティ検知結果やコンプライアンス状態をダッシュボードで一覧表示することが出来ます。

ここまで紹介した以下のサービスの検知結果は全てSecurityHubに集約可能です。

  • Config
  • IAMアクセスアナライザー
  • GuardDuty

また、それら検知結果に応じて「Lambda関数での自動修復」や後述の「Detectiveによる詳細調査」なども可能です。

CIS提供のAWSセキュリティ対策基準（CIS Amazon Web Services Benchmarks）によるセキュリティチェックも可能です。ただし、これもConfigのマネージドルールと同様、オールグリーンにするのは難しいので必要なものだけ有効化しましょう。

余力があれば、カスタムアクションで

CloudWatchEvent → SNS (AWS chatbot) → メールorチャットへ通知

という設定までしておくべきですが、長くなるのでここはまた別の機会にします。

SecurityHubを完全体まで進化させると、以下のような構成をとることができます。

securityhub.png

AWSのセキュリティサービスの検知結果をGuardDuty等からSecurityHubへ集約、異常があればSNSで通知、必要に応じてDetectiveで調査。こんな感じです。

流石に全部有効化する必要はありませんが、GuardDuty → SecurityHub → DetectiveのフローはAWSに関わる全ての人間にオススメです。

対応 (Respond)

  • 対応計画（RS.RP）
    • 検知されたサイバーセキュリティイベントにタイムリーかつ確実に対応できるよう、対応のプロセスおよび手順を実践し、維持管理する。
  • コミュニケーション（RS.CO）
    • 該当する場合に、司法当局による外部からの支援を含めるよう、社内および外部の利害関係者と対応アクティビティについて協議する。
  • 分析（RS.AN）
    • 十分な対応の保証および復旧アクティビティの支援に向けて、分析を実施する。
  • 低減（RS.MI）
    • イベントの拡大阻止、影響の低減、インシデントの除去に向けたアクティビティを実施する。
  • 改善（RS.IM）
    • これまでの検知/対応アクティビティから得られた教訓を採り入れて、組織の対応アクティビティを改善する。

■ Detectiveの有効化

「分析」を行う際に最高のサービスがあります。

AWS Detectiveです。2020/03/31にGAになりました！

プレビュー版を少し使ってみた所感だと、いざと言うときかなり期待できそうです。

DetectiveではCloudTrail/VPCフローログ/GuardDutyの検知結果から、関連するリソースやアクセス履歴などをグラフ分析によって処理します。イメージとしてはGuardDutyの検知結果の原因分析をするようなイメージです。5

※ 有効化してから実際に使えるようになるまで２週間近くかかります。

ソースIPアドレスから接続元エリアを可視化するのも自動でやってくれます。

現時点ではDetectiveは下記のタイプで絞り込み検索が可能です。

  • GuardDuty Findings
  • AWSアカウント（12桁の数字）
  • EC2インスタンス
  • IPアドレス
  • IAMロール
  • IAMユーザ
  • UserAgent

IAMユーザごとの振る舞い分析も可能なので、内部犯行やアカウント乗っ取りなどの調査もできるはずです。

まさに探偵ですね！真実はいつもひとつ！

復旧 (Recover)

  • 復旧計画（RC.RP）
    • 復旧のプロセスおよび手順を実践し、維持管理して、サイバーセキュリティイベントの影響を受けたシステムまたは資産をタイムリーかつ確実に復旧する。
  • 改善（RC.IM）
    • 得られた教訓を以後のアクティビティに採り入れて、復旧の計画およびプロセスを改善する。
  • コミュニケーション（RC.CO）
    • 復旧のアクティビティについて、コーディネートセンター、インターネットサービスプロバイダ、攻撃側システムの所有者、被害者、他のCSIRT、ベンダーなど、社内および外部の当事者と協議する。

■ バックアップの取得設定

インシデントが発生時の最悪の場合として、全てのリソースが消されていると言う事態6が想定されます。

全てのAWSリソースのバックアップを取得・管理するのは難しいですが、下記のような対策が挙げられます。

  • CloudFormation/SAM/CDKなどによるインフラ管理
  • AWS Backupによるバックアップ作成

S3バケット内のオブジェクトは特定期間削除できないようにロックすることが可能です。各種バックアップファイルはS3ファイルなどに格納されることが多いと思いますが、ロックをかけないと攻撃者から削除されてしまう可能性があるので注意してください。別のアカウントやローカル保存でも対応可能です。

おわりに

実は在宅勤務期間を利用してAWSセキュリティの社内向けポータルサイトを作成していました。7
本記事の内容はこのポータルサイトの一部です。

在宅勤務で生産性がスーパーサイヤ人だったので、予備知識０の状態から二週間くらいで出来ました。

security151.png

以上、在宅勤務民によるポエムでした。

参考

  1. ”アレ”とは…　おそらく在宅勤務が生産性が限界突破してアウトプットが溢れ出してしまったのだろう。わかる。 ↩

  2. 5つのコア機能の他にもティア、プロファイルなどの要素があります。 ↩

  3. ルールをたくさん設定するとそれだけお金もかかります。 ↩

  4. 最近ほとんどの社員が在宅勤務になったため、「不審なコンソールログイン」の検知結果が大量に上がってきます！GuardDutyすごい！ ↩

  5. GuardDutyは誤検知が多いため、結果を分析するツールに対するニーズが高かったのでしょう。 ↩

  6. How CodeSpaces was killed by security issues on AWS ↩

  7. HugoとCodePipeline+ECSで作成しています。ここらへんの内容もQiitaにまとめておこうと思いましたが、いつかまた在宅ハイになった時に… ↩

20
16
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
20
16

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?