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