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

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

View Slide

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

View Slide

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

View Slide

発表することになった経緯
前々回のJAWS-UG千葉#19で、
クールなダッシュボード作り中って最後にネタ振りしたや
つの回収です

View Slide

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

View Slide

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

View Slide

（C） Gunosy Inc. All Rights Reserved.
1. セキュリティ対応の背景

View Slide

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

View Slide

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

View Slide

2. Gunosyの組織体制とセキュリティ運用

View Slide

Gunosyの組織体制とセキュリティ運用
グノシーニュースパス au サービス Today 広告配信
グノシー
開発チーム
機械学習チーム
ニュースパス
開発チーム
au サービス
Today
開発チーム
広告配信
開発チーム
SREチーム
Gunosyの開発チーム体制

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

3. Security Hub運用で感じた課題

View Slide

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

View Slide

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

View Slide

Security Hubの画面
各アカウントのダッシュボード
委任アカウントのダッシュボード

View Slide

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

View Slide

4. Gunosyでの理想のSecurity Hub運用

View Slide

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

View Slide

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

View Slide

5. Security Lakeを使った解決策

View Slide

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

View Slide

Security Lakeのアーキテクチャ図

View Slide

Security Hubのアーキテクチャ図

View Slide

Security Lakeのアーキテクチャ図（再掲）
ここが増え
ている
ここが増え
ている

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

6. Security Lakeを使った実装

View Slide

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

View Slide

Glueの設定

View Slide

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
)

View Slide

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

View Slide

実装の過程で判明したアンドキュメントな仕様（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}/

View Slide

同じコントロール・同じリソースでfindings_uidが変わるケースがある
- Security Hubで指摘があったリソースを削除した場合に新しい
findings_uidで同じコ
ントロール・同じリソースに対する検知結果が出力される
- これは、findings_uidで集約、最新だけ取得するというクエリーでは
Security
Hubと同じ情報が取得できないことを意味します

View Slide

Security Hub、GuardDuty、Inspectorでそれぞれ出力されるカラムもその詳
細度も違う
- Stateの取り扱いが違ったり、出力されているカラムや詳細度、そもそも有用な情報が
出力されていないこともあったりします

View Slide


View Slide

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

View Slide

Inspector GuradDuty
Security Hub Kube-bench

View Slide

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

View Slide

QuickSightで作成したダッシュボード　Security Hub

View Slide

①クリックす
ると
②絞り込ま
れる

View Slide

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

View Slide

QuickSightで作成したダッシュボード　例外

View Slide

6. 効果検証

View Slide

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

View Slide

効果検証
Security Hubの画面

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

7. まとめ

View Slide

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

View Slide

まとめ
最後に
料金が爆発したり、もっといい感じの運用ができたら発表するので乞うご期待！

View Slide

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

View Slide

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

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

Takashi Yamaguchi

More Decks by Takashi Yamaguchi

Other Decks in Technology

Featured

Transcript

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

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

Takashi Yamaguchi

More Decks by Takashi Yamaguchi

Other Decks in Technology

Featured

Transcript

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

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