JAWS-UG千葉 #20 AWS Security Lakeを試してみたら最高の運用者体験だった

by Takashi Yamaguchi

Slide 1

Slide 1 text

株式会社 Gunosy Gunosy 技術戦略室 SREチームマネージャー山口隆史 2023年3月23日(木) AWS Security Lakeを試してみたら最高の運用者体験だった

Slide 2

Slide 2 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 2 自己紹介氏名：山口隆史(やまぐちたかし) 所属：株式会社Gunosy 技術戦略室 SREチームマネージャー業務：Pure SREとしての活動略歴：フリーランス、SIer等を渡り歩く→現職（2022/01〜）自称：プリセールスから運用までこなすフルスタックエンジニア好きなAWSサービス：AWS WAF、CloudShell、サポート

Slide 3

Slide 3 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 3 株式会社Gunosy ギリシャ語で「知識」を意味する「Gnosis（グノーシス）」＋「u(“you”)」「”Gnosis” for “you”」あなたのための知識　＝情報を届けるサービスを提供し続ける、という意味 ■ 2012年11月創業 ■ 2015年4月東証マザーズ上場 ■ 2017年12月東証第一部に市場変更 ■ 2022年4月東京証券取引所の市場一部からプライム市場に移行 ■ 従業員数 258名（2022年5月末現在連結ベース） ■ 事業内容 – 情報キュレーションサービスその他メディアの開発及び運営 ■ 提供サービス　グノシー、ニュースパス、 auサービスToday、YOU IN 企業理念「情報を世界中の人に最適に届ける」

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 6 目次 1. セキュリティ対応の背景 2. Gunosyの開発組織体制とセキュリティ運用 3. Security Hub運用で感じた課題 4. Gunosyでの理想のSecurity Hub運用 5. Security Lakeを使った解決策 6. Security Lakeを使った実装 7. 効果検証 8. まとめ

Slide 7

Slide 7 text

Slide 8

Slide 8 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 8 セキュリティ対応の背景セキュリティ対策に対する優先度が上がったキッカケはLog4j問題での対応 - ヤバめの脆弱性情報は個人がTwitter等で拾ってくる体制だった - Log4jはこれで拾えたが取りこぼしがあると致命的 - 調査が人力総力戦だったので、もうやりたくない定期的・自動的にスキャンして継続的に潰していくサイクルにしたい - セキュリティの設計への組み込みはベストプラクティスに従って対応していたが、レビュワー、実装者の個人のスキル任せになっていた

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 12 Gunosyの組織体制とセキュリティ運用アプリ開発アプリ運用オンコール対応コスト管理モニタリング設定セキュリティ・脆弱性対応 EKS・ECS運用障害対応 EKS VersionUP CI/CD運用 SLI /SLO管理運用障害対応（ポストモーテム）アクセス権限管理自動化・標準化インフラ運用管理 AWS環境設定全社的なガードレール運用ふりかえりの実施開発チーム CI/CD、監視、EKS/ECS 等を含むインフラの民主化ができている状態 SRE 「開発チームが新たなプロダクト価値の創造に集中できる状態を作る」がミッション開発チームとSREとの責任分担

Slide 13

Slide 13 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 13 Gunosyの組織体制とセキュリティ運用 SREが実施しているSecurity Hubの運用定例のふりかえりの準備 - SREがSecurity Hubの指摘を確認 - 指摘事項をトリアージ、対応事項をサジェストして課題JIRAを起票 - 基本Critical、Highは対応 - Critical指摘はSREが対応 - Highは開発チームが対応

Slide 14

Slide 14 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 14 Gunosyの組織体制とセキュリティ運用 SREが実施しているSecurity Hubの運用定例のふりかえり - SREが開発チームへ課題JIRAの対応を依頼 - 開発チームとSREが協議して対応有無を決定し、開発チームがタスクJIRA を起票して課題JIRAに関連付け - すでに起票されている課題JIRAに関連しているタスクJIRAのステータスを確認 - 完了確認、期日確認等々を実施

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 17 Security Hub運用で感じた課題ダッシュボードが使いにくいマルチアカウント環境での使いにくさ - アカウント単位にSeverity別の指摘数の集計ができない - どのアカウントにどれくらいのリスクが残っているかの確認ができない - 委任アカウントでリソースを例外にできない - 例外にしたリソース一覧がデフォルトでは表示できない - 一覧表示だとコントロール✖リソース表示になる - ドリルダウンできない - 件数が爆発しやすい

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 20 Security Hub運用で感じた課題 Security Lake登場までの回避策ダッシュボード - 委任アカウント側のダッシュボードは基本使わない - メンバーアカウントのSecurity Hub画面を使用してトリアージ - リソース単位の抑止もメンバーアカウント側で実行する必要があるので、トリアージと同時に実施委任アカウントのダッシュボードの用途 - コントロール単位で無効化する時のみ使用

Slide 21

Slide 21 text

Slide 22

Slide 22 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 22 Gunosyでの理想のSecurity Hub運用セキュリティベースライン評価を少ない工数で実施できる全てのアカウントのリスクの状況（要対応・未対応件数）が一覧で確認できる - セキュリティ指摘がアカウント別、Severity別に集計された一覧が確認できる - アカウント単位でリスク評価したい - 新規のセキュリティ指摘、通知済み・タスク化済みのセキュリティ指摘の一覧が確認できる - 絞り込んで一覧表示できる

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 25 Security Lakeを使った解決策 Amazon Security Lake は、クラウド、オンプレミス、およびカスタムソースからのセキュリティデータを、アカウントに保存されている専用のデータレイクに自動的に一元化します。Security Lake は、オープンスタンダードである Open Cybersecurity Schema Framework (OCSF) を採用しています。 OCSF のサポートにより、このサービスは、AWS からのセキュリティデータと幅広いエンタープライズセキュリティデータソースを正規化し、組み合わせることができます。 Security Lakeとは数ステップでセキュリティデータを自動的に一元化

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 32 Security Lakeを使った解決策ダッシュボードで実現したいこと大前提としてSecurity Hubと同じ情報が表示できる - コントロールの状況、指摘リソースのステータス等々が、さほど遅延せずに表示できる具体的には - アカウントごとにCritical、Highの件数が確認できる - 指摘クリックで、リソース一覧が確認できる（ドリルダウン） - リソースクリックで、そのリソースの指摘一覧が確認できる（ドリルアップ） - 例外にした指摘・リソース一覧が確認できる

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 37 Security Lakeを使った実装 AthenaのView CREATE OR REPLACE VIEW "view_latest_status_security_hub_resource_findings" AS with resource_finding as ( select t1.finding.uid as finding_uid , t1.region , t1.account_id , max_by(t1.metadata.product.version, t1.finding.modified_time) as metadata_product_version , max_by(t1.metadata.product.feature.uid, t1.finding.modified_time) as metadata_product_feature_uid , max_by(t1.metadata.product.feature.name, t1.finding.modified_time) as compliance.status, t1.finding.modified_time) as compliance_status -- key-value ＜省略＞ , max_by(t1.state_id, t1.finding.modified_time) as state_id , max_by(t1.severity_id, t1.finding.modified_time) as severity_id , max_by(t1.unmapped, t1.finding.modified_time) as unmapped -- map from original_security_lake.security_hub as t1 cross join unnest(resources) as t(resource) where t1.region = 'ap-northeast-1' group by 1, 2, 3 )

Slide 38

Slide 38 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 38 Security Lakeを使った実装 AthenaのView select t1.finding_uid , t1.region , t1.account_id , t1.metadata_product_version <省略> , from_unixtime(t1.event_time / 1000) as event_at , regexp_replace(t1.unmapped['ProductFields'], '\\n?') as unmapped_product_fields , t1.unmapped['NetworkPath'] as unmapped_network_path , t2.name as aws_account_name , t2.company_name as aws_account_company_name , t2.business_unit_name as aws_account_business_unit_name from resource_finding as t1 inner join business_budget."aws_accounts" as t2 on t1.account_id = t2.id where (t1.compliance_status not in('PASSED', 'NOT_AVAILABLE') or t1.compliance_status is null) and t2.company_name = 'Gunosy Inc.' and from_unixtime(t1.finding_modified_time / 1000) >= current_timestamp - interval '2' day

Slide 39

Slide 39 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 39 Security Lakeを使った実装実装の過程で判明したアンドキュメントな仕様（1）検知結果（Findings）が出力されるパーティション - 最初にFindingsがエクポートされたeventHourに出力され続ける - どういうことかと言うと、20230101に最初にFinding が作成されたら以降はずっとそのパーティションに出力され続ける - なので、Athenaでパーティションで絞ってクエリーできない S3のフォルダ構成 CloudTrail等とは違ってApache HiveのPartition形式になっている aws/ 　CLOUD_TRAIL/ 　ROUTE53/ 　SH_FINDINGS/ 　VPC_FLOW/ 　　region={リージョン名}/ 　　　accountId={アカウントID}/ 　　　　　　eventHour={yyyy}{mm}{dd}{hh}/

Slide 40

Slide 40 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 40 Security Lakeを使った実装実装の過程で判明したアンドキュメントな仕様（2）同じコントロール・同じリソースでfindings_uidが変わるケースがある - Security Hubで指摘があったリソースを削除した場合に新しい findings_uidで同じコントロール・同じリソースに対する検知結果が出力される - これは、findings_uidで集約、最新だけ取得するというクエリーでは Security Hubと同じ情報が取得できないことを意味します

Slide 41

Slide 41 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 41 Security Lakeを使った実装実装の過程で判明したアンドキュメントな仕様（3） Security Hub、GuardDuty、Inspectorでそれぞれ出力されるカラムもその詳細度も違う - Stateの取り扱いが違ったり、出力されているカラムや詳細度、そもそも有用な情報が出力されていないこともあったりします

Slide 42

Slide 42 text

Slide 43

Slide 43 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 43 Security Lakeを使った実装実装の過程で判明したアンドキュメントな仕様（4） unmappedカラムにしか出力されていない情報がある - 出力カラムはOCSFのスキーマで正規化されているが、そもそもマッピング先がなかったり（想像）で、unmappedカラムにしか出力されていないデータもある - https://schema.ocsf.io/classes/security_finding?extensions= - 3rdパーティー系のkube-benchはunmappedに有用な情報があったので取り出した

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 52 効果検証 SREのふりかえり活動でのSecurity Hub運用の変化これまでの運用 - 各アカウントにログインしてSecurity Hubの画面で有効にしているセキュリティ基準それぞれで指摘を確認 - ✖アカウント数分 - セキュリティ基準をクリックしてCritical、Highの指摘を確認 - クリックして画面遷移しないと確認ができない - Critical、Highの指摘があれば詳細を確認

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 57 効果検証料金面まだ検証できていませんが過去のセキュリティ実装で以下の爆発を経験しています - Security Hubを導入時にConfig起因の料金爆発 - GuardDutyを導入時にS3保護が起因の料金爆発なので、機能を絞って導入しています - 具体的には以下を有効化 - Security Hub findings

Slide 58

Slide 58 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 58 効果検証それでも残る課題運用面での課題 - リソースを例外にするのに各アカウントのマネコンで作業が必要 - GuardDuty、InspectorのRemediationの確認がSecurity Lakeの情報だけだと不足 - サービスの画面（マネコン）にも表示されていない場合もあるので、サービス自体のアップデート待ちダッシュボードの課題 - 新規の指摘かどうかの確認ができない - 指摘数の時系列変化の確認ができない

Slide 59

Slide 59 text

Slide 60

Slide 60 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 60 まとめ用法と料金に注意してSecurity Lakeを活用しましょう導入よりもその後の運用が大事 - 検知だけして満足しない、修復するまでが運用 - 運用を楽にするためには継続した改善活動が必要 Security LakeでSecurity Hubの情報をいい感じにダッシュボード化可能 - ぱっと見ですが3rd Partyのソリューションを使うよりも安価 - Security HubにはAWSのセキュリティサービスを統合できるのでより便利に！