Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
LegalForceの契約データを脅かすリスクの排除と 開発速度の向上をどうやって両立したか
aibou
May 20, 2022
Programming
0
2.1k
LegalForceの契約データを脅かすリスクの排除と 開発速度の向上をどうやって両立したか
aibou
May 20, 2022
Tweet
Share
More Decks by aibou
See All by aibou
SRE Lounge #7 Gunosy版「SREミッション」策定
aibou
9
5.1k
AWS Glueでリプレースしてみた/gunosy-use-glue
aibou
4
820
その接続先情報はどこに
aibou
0
2.7k
gunosy-beer-2016-07-27
aibou
1
580
Other Decks in Programming
See All in Programming
Running Laravel/PHP on AWS (AWS Builders Day Taiwan 2022)
dwchiang
0
130
Branching out to Jetpack Compose
chrisbanes
4
1.1k
Mobile Product Engineering
championswimmer
0
290
The strategies behind ddd – AdeoDevSummit 2022
lilobase
PRO
4
220
Overview of The Modern Data Stack / モダンデータスタック概論
satoshihirose
6
3.2k
RFC 9111: HTTP Caching
jxck
0
150
Amazon ECSのネットワーク関連コストの話
msato
0
610
"What's new in Swift"の要約 / swift_5_7_summary
uhooi
1
220
こそこそアジャイル導入しようぜ!
ichimichi
0
1.1k
はじめてのプルリク - BLEA 編
watany
0
140
IE Graduation (IE の功績を讃える)
jxck
20
12k
CUDA高速化セミナーvol.1 ~画像処理アルゴリズムの高速化~
fixstars
3
170
Featured
See All Featured
Adopting Sorbet at Scale
ufuk
63
7.6k
Build The Right Thing And Hit Your Dates
maggiecrowley
19
1.2k
Why Our Code Smells
bkeepers
PRO
324
55k
Design by the Numbers
sachag
271
17k
GitHub's CSS Performance
jonrohan
1020
420k
GraphQLとの向き合い方2022年版
quramy
16
8.2k
The Language of Interfaces
destraynor
148
20k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
100
5.9k
WebSockets: Embracing the real-time Web
robhawkes
57
5.1k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
12
920
From Idea to $5000 a Month in 5 Months
shpigford
373
44k
VelocityConf: Rendering Performance Case Studies
addyosmani
316
22k
Transcript
LegalForceの契約データを脅かすリスクの排除と 開発速度の向上をどうやって両⽴したか 株式会社LegalForce 浜地亮輔
2 ⾃⼰紹介 浜地亮輔(はまじ りょうすけ) 株式会社LegalForce(2020年9⽉〜 LegalForce(製品)のインフラエンジニア 好きな本:メカ屋のための脳科学⼊⾨ 趣味:NFL観戦🏈、クライミング
3 会社および製品紹介 • 株式会社LegalForce ⁃ 創業:2017年4⽉21⽇ ⁃ ミッション「全ての契約リスクを制御可能にする。」 • AI契約審査プラットフォーム「LegalForce」
⁃ 契約書ファイルをアップロードしてレビュー ⁃ 各項⽬のリスクや修正案が提⽰される ⁃ 2022年3⽉時点で導⼊社数2000社突破 https://legalforce-corp.com/company/
4 製品で扱っている契約データの重要性 • 様々な種類(類型)の契約書 ⁃ 普段の⽣活 ⁃ 賃貸借契約書 ⁃ 不動産売買契約書
⁃ 就業関係 ⁃ 雇⽤契約書 ⁃ 業務委託契約書 ⁃ 企業間 ⁃ 秘密保持契約書(NDA) ⁃ 事業譲渡契約書 ⁃ etc... • 第三者に漏えいすると犯罪に発展 ⁃ 企業間取引情報が漏れてインサイダー取引に発展 ⁃ 個⼈情報が漏れて詐欺や悪⽤など 会社間の業務締結情報 契約対象の個⼈情報 製品の売買額 インサイダー取引 各種詐欺 情報漏えいすると・・・
契約データは最優先で保護する必要がある! が、開発では課題も・・・
6 LegalForce開発チームでのセキュリティに関連する課題 どれをどうやって守っていいかわからない どこまで触っていいかわからない ただしく保護されているかわかりにくい
7 どれをどうやって守っていいのかわからない • 扱っている機密情報の種類や格納先が多い ⁃ すべての種類の機密情報の格納先を網羅し、最新状態を維持するのは困難 ⁃ すべての格納先で統⼀した基準で保護することは困難 • なんでもかんでも保護理論
⁃ 「たぶん漏れちゃいけないデータだから保護」→ 疲弊の始まり ⁃ ログの⼤半をマスキングすることにより調査困難 ⁃ 各機密情報に対する認識ズレ、都度相談、意⾒の対⽴などのコミュニケー ションコスト増⼤ • → ⼼理的不安、認知バイアス、認知過負荷 「これは暗号化すべきだろ」 「漏れても問題ないデータよ」 機密情報の種類 • 契約書ファイルデータ • 個人情報 • 利用顧客名 • ID/PASS • etc 格納先 • 各種データベース • オブジェクトストレージ • クラウドストレージ(Google Drive的な) • PC端末
8 どこまで触っていいかわからない • ⾃⾝の作業がどこまで影響を及ぼすか不明確 ⁃ 権限所持者や管理者に作業依頼 ⁃ うっかり機密情報にアクセスしたくないため • 何故?
→ 責務分離が完全でない ⁃ 環境区別が曖昧 ⁃ 「実はこれ本番環境でも使われてます」 ⁃ 記憶やバイアスによって判断されていることも ⁃ モノリスアプリケーション ⁃ どうしても広い権限になってしまう ⁃ 何故権限が必要なのか実装内容を掘り下げる必要がある • → 属⼈化、⼼理的不安、認知過負荷
9 ただしく保護されているかわかりにくい • ⼈やリソースに対する権限内容が⾮常に複雑 ⁃ 条件付き権限付与の権限内容が多数 ⁃ 環境差異もあって⾮常に難解 ⁃ 重複、打ち消しなど多数
• その権限内容に⾄った背景が不明瞭 ⁃ いわゆる「秘伝のタレ化」 ⁃ 正しい状態がわからないので放置 ⁃ 変更履歴も記録・追跡しづらい • → 属⼈性、⼼理的不安、認知過負荷
10 認知過負荷に関する話題 SRE NEXT 2020 基調講演「分散アプリケーションの信頼性観測技術に関する研究」より 「認知過負荷はタスク処理時に過失やある種の⼲渉 を⽣じさせる」 「(認知過負荷状態の)被験者は主観的に複雑なタ スクで悪いパフォーマンスになる傾向がある」
Wikipedia 「Cognitive Load」より 認知負荷が⾼い = 変更に対するリスク制御が困難、もしくはリスク肥⼤化のおそれ → 変更レビューや動作テストの⼯数増⼤のおそれ → デプロイ頻度の減少 サイトリライアビリティワークブック17章「過負荷の特定と回復」より 「認知過負荷は、実際の過負荷なのであり、他の要 素で⽣じた作業過負荷と同じようなインパクトを チームに与えます。(中略)⼀部のチームメンバー にとっての認知の過負荷が、⾮常に急速にチーム全 体の過負荷につながる場合があるのです。」
認知負荷をコントロールして 全ての契約(データの)リスクを制御可能にするぞ!
12 LegalForceで実践したセキュリティ観点での認知過負荷に対する取り組み 守るべきものの定義 責任領域の分割や予防的ガードレールの導⼊ ⼈に対する権限情報のコード化と⾃動デプロイ 権限内容の簡素化
13 実施したこと:守るべきものの定義 • 全社的に「情報資産分類」を整備 ⁃ 資産レベルの定義 ⁃ 影響度、法規則など ⁃ 資産レベルごとに実施する施策を定義
⁃ 監視、利⽤条件など ⁃ 各情報と資産レベルのマッピング ⁃ → バラバラだった認知が統⼀ • 開発側での対応 ⁃ 情報資産分類を元に現状洗い出し ⁃ 過剰に保護していたものは制限を緩める ⁃ ログのマスキング解除 ⁃ アクセス制限の緩和 etc ⁃ 新規機能開発時はPRRでデータや格納先を確認 ⁃ → 迷いがなくなり判断が早くなった
14 補⾜:Production Readiness Review(PRR) & Premortem • ⼤きめの機能開発時に必ずPRRとPremortemを実施 ⁃ PRR:開発したアプリが本番環境で受け⼊れられるかの確認
⁃ 実施タイミング的には実装後&リリース前なので「単純PRRモデル」 ⁃ Premortem:「失敗(=障害)が発⽣するとしたら何が原因か」を議論 • PRR ⁃ スケーラビリティ・可⽤性・モニタリングなどの観点でチェック ⁃ 新しく扱う機密情報があるか、ある場合はどのレベルに該当するか ⁃ 新しく扱う格納先がある場合、機密データが含まれるかどうか • Premortem ⁃ minispecやシステム構成図、シーケンス図を元に考えられる障害・ 不具合などを議論 ⁃ 扱う機密情報が漏えいする⼿段がないかも議論
15 実施したこと:責任領域の分割や予防的ガードレールの導⼊ • 責任領域ごとにリソースを分割 ⁃ AWSアカウントを環境ごとに分割 ⁃ 構成⾒直しの際にAWS SSOも導⼊ ⁃
⾮本番環境での検証難易度の低下を実現 ⁃ システムを関⼼事ごとに分割 ⁃ 可能な限り機密データ格納先へのアクセス元を減らす ⁃ → 責任領域外への影響を考えることが減る • 予防的ガードレール導⼊ ⁃ AWS Organizations SCP ⁃ アカウント全域で特定の⾏動を制限 ⁃ 例:本番環境でのサーバログイン、秘匿情報閲覧など ⁃ → 作業者が事情を知らずに⾏動してもエラーで無害 • ⾏動監視 ⁃ CloudTrailを始めとした各種ログを監査ログ基盤に集約&監視 ⁃ Anomalyな⾏動も検知 AWS account VPC VPC VPC AWS account VPC AWS account VPC AWS account VPC SCP CloudTrail VPC Flow log SEIM製品
16 実施したこと:⼈に対する権限情報のコード化と⾃動デプロイ • 権限情報をTerraform化 ⁃ 管理対象 ⁃ AWS SSO, AWS
Organizations ⁃ AzureAD(社内管理ツールのログインで利⽤) ⁃ コード化対象 ⁃ 権限内容 ⁃ ガードレール(SCP) ⁃ ⼈やグループとログイン先のマッピング • → 誰でも閲覧・編集できる ⁃ 事情や細かい権限内容は開発者の⽅が詳しい ⁃ ⼊退職管理は情シスのほうが詳しい ⁃ → ⽚⽅の組織に作業依存することがなくなった • → 権限変更の履歴を追跡できる • ⾃動デプロイ環境も整備 ⁃ 常にコードの状態を正とできる AWS Organizations AWS SSO AzureAD ・開発者 ・情シス セキュリティ責任者 レビュー& マージ 編集 デプロイパイプライン
17 実施したこと:既存の権限内容の簡素化 • 複雑だった権限内容の簡素化 ⁃ 既存の権限内容を洗い出し ⁃ 条件分岐図と真理値表、論理式を作成 ⁃ これらをレビュー後に実際に権限内容を実装
• 環境差をなくす ⁃ 本番環境と⾮本番環境で条件が微妙に異なっていた ⁃ 「現状がこうだから」→「こうあるべきだ」を規定 ⁃ IaCおよび環境間共通化により、環境差を最⼩化を実現 • → 認知が可能になったことで変更やレビューが容易
18 実践の効果 • 「設計時の迷いや偏りがなくなった」 • 「インシデントリスクを減らせていそう」 どれをどうやって守っていいかわからない • 「環境起因で発⽣していた作業ミスが減った」 •
「AWSを利⽤した開発の敷居が下がった」 どこまで触っていいかわからない • 「不明確だった仕様が明らかになったことで⼼理的不安が減った」 • 「複雑さが減って変更しやすくなった」 ただしく守られているかわかりにくい • 開発者に体験向上した点を聞いてみた
結論 SREの関⼼事のひとつである「認知負荷の軽減」は 情報保護やセキュリティという観点においても 変更時のリスク制御や信頼性向上を可能とする
20 We are hiring