Upgrade to Pro — share decks privately, control downloads, hide ads and more …

LegalForceの契約データを脅かすリスクの排除と 開発速度の向上をどうやって両立したか

Db8ec54bcaba4695821acf233a25afe9?s=47 aibou
May 20, 2022

LegalForceの契約データを脅かすリスクの排除と 開発速度の向上をどうやって両立したか

Db8ec54bcaba4695821acf233a25afe9?s=128

aibou

May 20, 2022
Tweet

More Decks by aibou

Other Decks in Programming

Transcript

  1. LegalForceの契約データを脅かすリスクの排除と 開発速度の向上をどうやって両⽴したか 株式会社LegalForce 浜地亮輔

  2. 2 ⾃⼰紹介 浜地亮輔(はまじ りょうすけ) 株式会社LegalForce(2020年9⽉〜 LegalForce(製品)のインフラエンジニア 好きな本:メカ屋のための脳科学⼊⾨ 趣味:NFL観戦🏈、クライミング

  3. 3 会社および製品紹介 • 株式会社LegalForce ⁃ 創業:2017年4⽉21⽇ ⁃ ミッション「全ての契約リスクを制御可能にする。」 • AI契約審査プラットフォーム「LegalForce」

    ⁃ 契約書ファイルをアップロードしてレビュー ⁃ 各項⽬のリスクや修正案が提⽰される ⁃ 2022年3⽉時点で導⼊社数2000社突破 https://legalforce-corp.com/company/
  4. 4 製品で扱っている契約データの重要性 • 様々な種類(類型)の契約書 ⁃ 普段の⽣活 ⁃ 賃貸借契約書 ⁃ 不動産売買契約書

    ⁃ 就業関係 ⁃ 雇⽤契約書 ⁃ 業務委託契約書 ⁃ 企業間 ⁃ 秘密保持契約書(NDA) ⁃ 事業譲渡契約書 ⁃ etc... • 第三者に漏えいすると犯罪に発展 ⁃ 企業間取引情報が漏れてインサイダー取引に発展 ⁃ 個⼈情報が漏れて詐欺や悪⽤など 会社間の業務締結情報 契約対象の個⼈情報 製品の売買額 インサイダー取引 各種詐欺 情報漏えいすると・・・
  5. 契約データは最優先で保護する必要がある! が、開発では課題も・・・

  6. 6 LegalForce開発チームでのセキュリティに関連する課題 どれをどうやって守っていいかわからない どこまで触っていいかわからない ただしく保護されているかわかりにくい

  7. 7 どれをどうやって守っていいのかわからない • 扱っている機密情報の種類や格納先が多い ⁃ すべての種類の機密情報の格納先を網羅し、最新状態を維持するのは困難 ⁃ すべての格納先で統⼀した基準で保護することは困難 • なんでもかんでも保護理論

    ⁃ 「たぶん漏れちゃいけないデータだから保護」→ 疲弊の始まり ⁃ ログの⼤半をマスキングすることにより調査困難 ⁃ 各機密情報に対する認識ズレ、都度相談、意⾒の対⽴などのコミュニケー ションコスト増⼤ • → ⼼理的不安、認知バイアス、認知過負荷 「これは暗号化すべきだろ」 「漏れても問題ないデータよ」 機密情報の種類 • 契約書ファイルデータ • 個人情報 • 利用顧客名 • ID/PASS • etc 格納先 • 各種データベース • オブジェクトストレージ • クラウドストレージ(Google Drive的な) • PC端末
  8. 8 どこまで触っていいかわからない • ⾃⾝の作業がどこまで影響を及ぼすか不明確 ⁃ 権限所持者や管理者に作業依頼 ⁃ うっかり機密情報にアクセスしたくないため • 何故?

    → 責務分離が完全でない ⁃ 環境区別が曖昧 ⁃ 「実はこれ本番環境でも使われてます」 ⁃ 記憶やバイアスによって判断されていることも ⁃ モノリスアプリケーション ⁃ どうしても広い権限になってしまう ⁃ 何故権限が必要なのか実装内容を掘り下げる必要がある • → 属⼈化、⼼理的不安、認知過負荷
  9. 9 ただしく保護されているかわかりにくい • ⼈やリソースに対する権限内容が⾮常に複雑 ⁃ 条件付き権限付与の権限内容が多数 ⁃ 環境差異もあって⾮常に難解 ⁃ 重複、打ち消しなど多数

    • その権限内容に⾄った背景が不明瞭 ⁃ いわゆる「秘伝のタレ化」 ⁃ 正しい状態がわからないので放置 ⁃ 変更履歴も記録・追跡しづらい • → 属⼈性、⼼理的不安、認知過負荷
  10. 10 認知過負荷に関する話題 SRE NEXT 2020 基調講演「分散アプリケーションの信頼性観測技術に関する研究」より 「認知過負荷はタスク処理時に過失やある種の⼲渉 を⽣じさせる」 「(認知過負荷状態の)被験者は主観的に複雑なタ スクで悪いパフォーマンスになる傾向がある」

    Wikipedia 「Cognitive Load」より 認知負荷が⾼い = 変更に対するリスク制御が困難、もしくはリスク肥⼤化のおそれ → 変更レビューや動作テストの⼯数増⼤のおそれ → デプロイ頻度の減少 サイトリライアビリティワークブック17章「過負荷の特定と回復」より 「認知過負荷は、実際の過負荷なのであり、他の要 素で⽣じた作業過負荷と同じようなインパクトを チームに与えます。(中略)⼀部のチームメンバー にとっての認知の過負荷が、⾮常に急速にチーム全 体の過負荷につながる場合があるのです。」
  11. 認知負荷をコントロールして 全ての契約(データの)リスクを制御可能にするぞ!

  12. 12 LegalForceで実践したセキュリティ観点での認知過負荷に対する取り組み 守るべきものの定義 責任領域の分割や予防的ガードレールの導⼊ ⼈に対する権限情報のコード化と⾃動デプロイ 権限内容の簡素化

  13. 13 実施したこと:守るべきものの定義 • 全社的に「情報資産分類」を整備 ⁃ 資産レベルの定義 ⁃ 影響度、法規則など ⁃ 資産レベルごとに実施する施策を定義

    ⁃ 監視、利⽤条件など ⁃ 各情報と資産レベルのマッピング ⁃ → バラバラだった認知が統⼀ • 開発側での対応 ⁃ 情報資産分類を元に現状洗い出し ⁃ 過剰に保護していたものは制限を緩める ⁃ ログのマスキング解除 ⁃ アクセス制限の緩和 etc ⁃ 新規機能開発時はPRRでデータや格納先を確認 ⁃ → 迷いがなくなり判断が早くなった
  14. 14 補⾜:Production Readiness Review(PRR) & Premortem • ⼤きめの機能開発時に必ずPRRとPremortemを実施 ⁃ PRR:開発したアプリが本番環境で受け⼊れられるかの確認

    ⁃ 実施タイミング的には実装後&リリース前なので「単純PRRモデル」 ⁃ Premortem:「失敗(=障害)が発⽣するとしたら何が原因か」を議論 • PRR ⁃ スケーラビリティ・可⽤性・モニタリングなどの観点でチェック ⁃ 新しく扱う機密情報があるか、ある場合はどのレベルに該当するか ⁃ 新しく扱う格納先がある場合、機密データが含まれるかどうか • Premortem ⁃ minispecやシステム構成図、シーケンス図を元に考えられる障害・ 不具合などを議論 ⁃ 扱う機密情報が漏えいする⼿段がないかも議論
  15. 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. 16 実施したこと:⼈に対する権限情報のコード化と⾃動デプロイ • 権限情報をTerraform化 ⁃ 管理対象 ⁃ AWS SSO, AWS

    Organizations ⁃ AzureAD(社内管理ツールのログインで利⽤) ⁃ コード化対象 ⁃ 権限内容 ⁃ ガードレール(SCP) ⁃ ⼈やグループとログイン先のマッピング • → 誰でも閲覧・編集できる ⁃ 事情や細かい権限内容は開発者の⽅が詳しい ⁃ ⼊退職管理は情シスのほうが詳しい ⁃ → ⽚⽅の組織に作業依存することがなくなった • → 権限変更の履歴を追跡できる • ⾃動デプロイ環境も整備 ⁃ 常にコードの状態を正とできる AWS Organizations AWS SSO AzureAD ・開発者 ・情シス セキュリティ責任者 レビュー& マージ 編集 デプロイパイプライン
  17. 17 実施したこと:既存の権限内容の簡素化 • 複雑だった権限内容の簡素化 ⁃ 既存の権限内容を洗い出し ⁃ 条件分岐図と真理値表、論理式を作成 ⁃ これらをレビュー後に実際に権限内容を実装

    • 環境差をなくす ⁃ 本番環境と⾮本番環境で条件が微妙に異なっていた ⁃ 「現状がこうだから」→「こうあるべきだ」を規定 ⁃ IaCおよび環境間共通化により、環境差を最⼩化を実現 • → 認知が可能になったことで変更やレビューが容易
  18. 18 実践の効果 • 「設計時の迷いや偏りがなくなった」 • 「インシデントリスクを減らせていそう」 どれをどうやって守っていいかわからない • 「環境起因で発⽣していた作業ミスが減った」 •

    「AWSを利⽤した開発の敷居が下がった」 どこまで触っていいかわからない • 「不明確だった仕様が明らかになったことで⼼理的不安が減った」 • 「複雑さが減って変更しやすくなった」 ただしく守られているかわかりにくい • 開発者に体験向上した点を聞いてみた
  19. 結論 SREの関⼼事のひとつである「認知負荷の軽減」は 情報保護やセキュリティという観点においても 変更時のリスク制御や信頼性向上を可能とする

  20. 20 We are hiring