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

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

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

（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 企業理念「情報を世界中の人に最適に届ける」

（C） Gunosy Inc. All Rights Reserved. PAGE | 4 発表することになった経緯
前々回のJAWS-UG千葉#19で、クールなダッシュボード作り中って最後にネタ振りしたやつの回収です

（C） Gunosy Inc. All Rights Reserved. PAGE | 5 アジェンダ
話すこと - AWS Security Lakeを使ったAWS Security Hub運用の実例 - QuickSightで作成したダッシュボードの実例話さないこと - AWSクラウドセキュリティ本についての感想 - セキュアな設計に関すること - セキュリティリスクの評価 - 等々

（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. まとめ

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

（C） Gunosy Inc. All Rights Reserved. PAGE | 9 セキュリティ対応の背景
定期的・自動的にスキャンして継続的に潰していくサイクルにしたい [定期･自動] スキャン DBとの照合トリアージ対応なんかやばいぞってなる急いで調査対応 As-Is To-Be

（C） Gunosy Inc. All Rights Reserved. PAGE | 11 Gunosyの組織体制とセキュリティ運用
グノシーニュースパス au サービス Today 広告配信グノシー開発チーム機械学習チームニュースパス開発チーム au サービス Today 開発チーム広告配信開発チーム SREチーム Gunosyの開発チーム体制

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

SREが実施しているSecurity Hubの運用定例のふりかえりの準備 - SREがSecurity Hubの指摘を確認 - 指摘事項をトリアージ、対応事項をサジェストして課題JIRAを起票 - 基本Critical、Highは対応 - Critical指摘はSREが対応 - Highは開発チームが対応

SREが実施しているSecurity Hubの運用定例のふりかえり - SREが開発チームへ課題JIRAの対応を依頼 - 開発チームとSREが協議して対応有無を決定し、開発チームがタスクJIRA を起票して課題JIRAに関連付け - すでに起票されている課題JIRAに関連しているタスクJIRAのステータスを確認 - 完了確認、期日確認等々を実施

どんな内容のセキュリティ運用をしているか「AWSではじめるクラウドセキュリティ」本の言葉を借りるとベースラインアプローチによるベースラインの管理

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

Hub運用で感じた課題ダッシュボードが使いにくい単一アカウント環境での使いにくさ - 表示される点数がコントロールの失敗割合 - リスク評価できない

Hub運用で感じた課題 Security Hubの画面各アカウントのダッシュボード委任アカウントのダッシュボード

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

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

（C） Gunosy Inc. All Rights Reserved. PAGE | 23 Gunosyでの理想のSecurity
Hub運用セキュリティベースライン評価を少ない工数で実施できる指摘があるリソースが一覧で確認できる - ドリルダウンで指摘からリソース一覧が確認できる - できればそのリソースの詳細か指摘の詳細を確認したい - 例外にできると最高

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

Lakeを使った解決策 Security Lakeのアーキテクチャ図

Lakeを使った解決策 Security Hubのアーキテクチャ図

Lakeを使った解決策 Security Lakeのアーキテクチャ図（再掲）ここが増えているここが増えている

Lakeを使った解決策要するに何ができるの？簡単な設定でSecurity Hubに保存したデータを正規化した形でS3にエクスポートできる S3にエクスポートできるとAthenaでクエリーできる AthenaでクエリーできるとQuickSightでダッシュボードが作れる

Lakeを使った解決策 Security Lakeに期待していたこと S3へのエクスポートのマネージドサービス化 - Security HubでもS3にエクスポートはできたが、自動化するには作り込みが必要だった

Lakeを使った解決策理想の運用方法を実現するための要件定義 SREが行うふりかえり活動で実施しているSecurity Hubの指摘確認（セキュリティベースライン管理）を、Security Lakeを活用したダッシュボードを作成し利用することで今より少ない工数で実施できるようにする

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

Lakeを使った実装アーキテクチャ図 Amazon Security Lake AWS Security Hub Bucket AWS Glue Data Catalog Amazon Athena Amazon QuickSight

Lakeを使った実装 Glueの設定

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 )

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

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}/

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

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

Lakeを使った実装実装の過程で判明したアンドキュメントな仕様（3）

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

Lakeを使った実装実装の過程で判明したアンドキュメントな仕様（4） Inspector GuradDuty Security Hub Kube-bench

Lakeを使った実装 QuickSightで作成したダッシュボード　一覧 Inspectorは Imageの最新版で最新版では対応ずみでも、全てのImageの検出結果が合計されるため、指摘数が多くなります

Lakeを使った実装 QuickSightで作成したダッシュボード　Security Hub

Lakeを使った実装 QuickSightで作成したダッシュボード　Security Hub ①クリックすると ②絞り込まれる

Lakeを使った実装 QuickSightで作成したダッシュボード　全部 Security Hub に統合した情報全て表示

Lakeを使った実装 QuickSightで作成したダッシュボード　例外

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

Security Hubの画面

SREのふりかえり活動でのSecurity Hub運用の変化ダッシュボード作成後の運用 - Security Lakeのダッシュボードの一覧を確認 - Critical、Highの指摘があればSecuity Hubのタブで詳細を確認 - 新しい指摘があれば、アカウントにログインして詳細を確認

（再掲）QuickSightで作成したダッシュボード　一覧

（再掲）QuickSightで作成したダッシュボード　Security Hub ①クリックすると ②絞り込まれる

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

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

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

情報を世界中の人に最適に届ける

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

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

More Decks by Takashi Yamaguchi

Other Decks in Technology

Featured

Transcript

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

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