オーダーメード設計書
コードや内部構成を外部へ出したくない企業向け。業務要件から取得許可の条件を設計し、実装は顧客側のエンジニアで進められます。
- 取得上限・累積上限
- 時間・承認人数と役割
- 送信先・緊急経路
- 監査証跡・復旧条件
- 導入優先順位
最大被害量の設計 / Maximum Loss Design
「侵入されない会社」を約束するのではなく、
侵入されても、全件流出しにくい会社へ。
管理者アカウントが1つ破られたとき、何件の個人情報まで届きますか？
100件ですか。
10,000件ですか。
ALLそれとも全件ですか。
多要素認証（MFA）・パスキー・生体認証などは、侵入の可能性を下げます。Sensitive Data Egress Gateは、その先──1つが破られた後の最大到達量を小さくする設計を扱います。
1つの認証情報管理者アカウント / APIキー
Sensitive Data Egress Gate量 · 時間 · 承認 · 送信先
- 100一度の取得量許可された範囲内で
- 10,000一定時間内の累積量繰り返し取得も合算
- ALL全量には、別の条件複数承認 + 待機 + 専用経路
数量は設計イメージです。実際の上限・承認条件は、各社の業務に合わせて定めます。
守る対象
個人情報 / 本人確認資料 / 医療情報 / 給与・銀行口座 / 顧客・法人確認（KYC・KYB）/ 顧客情報
02 / 設計の考え方
ATMは、暗証番号だけで全額を引き出せない。
ATMでは、暗証番号を知っていても口座残高の全額を一度に引き出せない。機微なデータにも同じように、一度に失える最大量を設計できます。
これは単に取得の頻度を制限する話ではありません。
量・時間・判断する人・送信先を組み合わせて、データを外へ出す条件を定めます。
01一度の取得量一度に何件までか
02累積取得量繰り返すと何件までか
03時間枠どの期間で数えるか
04追加承認誰の判断を加えるか
05送信先どこへ出せるか
06権限変更後の待機新しい権限をいつ使えるか
07緊急時の特別経路例外時に、誰が何を許可するか
03 / 5段階の自己診断
あなたのシステムは、どの段階ですか？
1つの認証情報が悪用されたとき、実際にどこまで取得できるかを考えてみてください。
これは点数ではなく、条件の見取り図です。段階5が、すべての会社の正解ではありません。業務要件に応じて適切な構造は異なります。選択だけで実装の有効性が確認されるものではありません。
分からない場合は、今どの条件なら全量を取得できるかを整理するところから始められます。
04 / 現在の状態 → 変更後
データが出るまでの経路を、設計する。
影響の大きい取得許可ほど、取り消せなくなる前に時間と介入の余地を残します。
- ログイン
- 管理者権限
- 全件を取得
- ログイン誰が取得するか
- アクセス範囲どのデータへ届くか
- 取得量の条件Volume Gate一度の量 + 累積量
- 時間の条件Time Gate時間枠 + 待機時間
- 承認の条件Approval Gate業務に応じた複数承認
- 送信先の条件Destination Gate許可された送信先 + 経路
- 取得許可Release定めた条件の範囲で
即時にしない単独にしない介入の余地を残す
05 / 何を設計するか
セキュリティ機能を増やす前に、「1つ破られたとき最大何件失えるか」を設計します。
多要素認証（MFA）、権限管理、取得頻度の制限（Rate Limit）、承認フロー、情報持ち出し対策（DLP）などを個別に見るだけでなく、「最大何件まで到達できるか」という1つの境界にまとめ、社内で実装できる目標とする状態へ変換します。
評価の中心は、最大到達量（Maximum Extraction）です。1つの認証情報が悪用された場合、確認できた経路の範囲で最大何件まで到達できるかを整理します。
経路をまたぐ分析（cross-path analysis）、脅威の想定（threat modeling）、被害が及ぶ範囲の分析（blast-radius analysis）は、既存の安全性確認でも行われます。本サービスは対象と評価軸を絞り、一つの成果物にまとめます。
一般的な幅広い安全性の確認（Security Review）
- 複数のリスク・攻撃経路・制御を広く確認
- 指摘事項・改善提案を返す場合がある
Sensitive Data Egress Gate
- 機微データの取得・持ち出しに対象を限定
- 最大到達量を評価の中心にする
- 現在の状態 → 目標とする状態の境界値を設計
- 実装後に確認する条件まで定義
広く見る代わりに、「最大何件失えるか」を深く設計する。
経営側と実装側が、同じ境界を見て判断できます。
経営側は「どこまでの損失を許容するか」を判断し、エンジニア側は「何を実装すればその境界になるか」を確認できます。同じ設計書で、双方の判断をつなぎます。
- 現在の状態Current State現在どこまで行けるか
- 目標とする状態Target Stateどこまで許すか
- 何を変えるかDesign Delta何を変えるか
- 実装後の確認Verification実装後に確認すること
06 / 設計と進め方
設計から、実装後の確認まで。
社内の状況と、開示できる範囲に合わせて進めます。
見せられる範囲の実装を確認
見せられる範囲のコード・構成・テストを確認。量・時間・承認・経路の条件が、意図どおり実装されているかを整理します。
共有できる情報に合わせて、確認範囲を定めます。
実装後の被害範囲を確認
実装後に、設計どおり被害が及ぶ範囲が制限されているかを確認。確認できた条件と、残る未確認事項を明確にします。
合意した範囲・環境で確認します。
成果物サンプル
実際に何が納品されるか、3ページで確認できます。
架空企業を使って、
- 現在の状態Current State
- 最大到達量Maximum Extraction
- 目標とする状態Target State
- 時間・承認する立場・送信先・取得量・例外経路Time / Seat / Destination / Volume / Exception
- 実装後の確認Verification
までを設計書にしたサンプルです。
成果物サンプルを見る（PDF）
完全架空企業を使った設計例です。
- 設計書を作成Design
- 社内で実装
- 実装後の確認Verification
承認人数に一律の正解はありません。3名のうち2名、5名のうち3名の承認（2-of-3 / 3-of-5）などは設計例であり、実際の役割・条件・時間は各社の業務要件に合わせて定めます。
07 / 共有できる範囲から始める
最初からすべてを預ける必要はありません
ソースコードや内部構成をすべて開示する必要はありません。まずは、対象となる取得経路、現在の上限、承認条件、送信先、例外経路など、設計に必要な範囲だけから始められます。
設計書の作成だけを外部へ依頼し、実装は御社のエンジニアが行う形でも構いません。必要であれば、実装後の確認だけ再度外部から依頼できます。
08 / PUBLIC TECHNICAL WORK
公開された修正履歴を、追跡できます。
Nagata Shinichi（GitHub: shin4141）の公開OSS実装・検証記録です。元のPRとcommitから、修正内容とレビュー・採用経緯を確認できます。
技術実績は公開GitHub履歴から確認できます。必要に応じて、追加の技術確認方法も相談できます。
30件超のOSS修正が上流採用
公開台帳から、元のPRと採用記録へ辿れます。
修正・採用の公開台帳を見るActionbaseでmerge
エンコード失敗時にも、借りたバッファをプールへ戻す修正。元のPRでレビューとmergeを確認できます。
PR #505を確認するOpenSSLで上流採用
乱数seed source構築の再帰に関する修正が、maintainer commit経由でmasterへ採用。直接PR mergeとは別の採用経路です。
採用commitを確認するこれらは公開OSSへの貢献です。顧客契約実績、有償security consultingの実績、掲載企業からの推薦を示すものではありません。
コードで動く証明
設計だけではありません。動く参照実装があります。
架空データを使った最小の参照実装（Reference Implementation）を公開しています。境界の働きを、コードとテストで確認できます。
- 現在
- 1つの認証情報 → 全量に届く可能性Current: 1 credential → potentially ALL
- 目標
- 1つの認証情報 → 取得量に上限Target: 1 credential → bounded
- 500件は許可、501件は停止。直近24時間の累積にも上限。
- 大量取得には独立承認。送信先を変えれば、既存承認は失効。
- 最終責任者だけの全量取得・待機前の取得は停止。正式な申請から通知・待機・独立承認・最終承認を経て取得を許可。
本番用のセキュリティ製品ではなく、設計思想を確認する参照実装です。取得上限や承認する立場はサンプルであり、御社への推奨値ではありません。
自分のAIと検討する
「この人に頼んで大丈夫？」を、あなたのAIに聞いてください。
この設計が良いかどうかと、御社に今必要かどうかは別です。私を最初から全面的に信用する必要はありません。
このページ、成果物サンプル、公開参照実装を、普段お使いのAIに見せてください。会社の状況をそのAIに共有している場合は、利用できる文脈も含めて「うちの場合は必要か」を評価させてください。
設計だけ外部で作り、実装は社内担当者や既存ベンダーに任せる、という結論でも構いません。
AIの回答は判断材料の一つです。監査・保証・認証ではありません。リンク先を読めない場合もあるため、確認できた内容と確認できなかった内容を分けて評価させてください。
09 / START WITH THE CONDITIONS
全量到達の条件を整理する。
管理者権限やAPIキーが1つ悪用された場合、現在どこまで到達できるのか。コードの全面開示なしでも、まず条件整理から始められます。
全量到達の条件を相談するメールアプリが開きます。現在の取得経路と、共有できる範囲からお知らせください。
AI・ソフトウェアシステムの実装／外部検証
- GitHub
- github.com/shin4141
- 所在地
- 神奈川県茅ヶ崎市