Finite Field

Security & Data Handling

預かるデータを、
曖昧に扱わない。

どのデータを、何のために、誰が、どこで、いつまで扱うのか。数理プロトタイプから本番運用まで、境界と責任を先に決め、確認できる資料として残します。

完全な安全を保証する表現はしません。 認証取得を示すページではありません。 案件ごとの合意内容を優先します。
DATA CONTROL PLANEPROJECT / 001
01お客様元データ・業務ルール
必要最小限
02FINITE FIELD設計・開発・検証
合意した範囲
03利用サービスクラウド・外部連携
目的事前に定義
アクセス必要者に限定
保存場所と期間を合意
削除方法と証跡を決定
DESIGN BEFORE TRANSFER境界を決めてから受領
SCROLL

Our position

「安全です」ではなく、判断材料を公開します。

セキュリティは、製品名や一つの機能だけでは決まりません。データの性質、利用目的、組織、運用、委託先まで含めて設計し、実施状況を確認できることを重視します。

01 / Minimize

必要なデータだけ受け取る

検証目的に不要な氏名、住所、連絡先、自由記述を外せるかを先に確認します。全件ではなく、少量の匿名化サンプルから始める設計を優先します。

02 / Boundary

送る前に境界を決める

保存場所、閲覧者、外部サービス、AI利用、保持期間、削除方法を、データ受領前または本番移行前に合意します。

03 / Evidence

実施内容を資料に残す

データフロー、アクセス権、委託先、バックアップ、削除、インシデント連絡先などを、確認可能な成果物として残します。

公開すること方針、設計項目、確認できる資料
案件で確定すること具体的なサービス、権限、保存期間、試験範囲
公開しないこと攻撃に悪用され得る詳細設定や秘密情報

Data journey

受領から削除まで、段階ごとに決めます。

同じデータでも、無料診断、プロトタイプ、本番運用では必要な管理が異なります。各段階で「受け取るもの」「決めること」「残す証跡」を分けます。

INTAKE

まずは説明資料と匿名化サンプルから。

低い取扱量を優先

受け取る例

  • 現在のExcelの列構成
  • 架空または匿名化した数行
  • 業務ルールと困りごと
  • 改善したい指標

事前に決めること

  • 実名が必要か
  • 添付の送付方法
  • 相談対応者の範囲
  • 相談後の保持期間

残せる資料

  • 受領データ一覧
  • 利用目的メモ
  • 削除予定日
  • 追加確認事項

Security profile builder

案件ごとの設計案を、約2分で整理。

これは監査や保証ではなく、初回打ち合わせで確認すべき事項を整理するための設計補助です。連絡先の入力は不要です。

Step 01 / Data class

扱う可能性があるデータを選択

最も慎重な扱いが必要な種類を基準に設計案を作ります。複数選択できます。

Control model

予防だけでなく、検知・対応・復旧まで。

NIST Cybersecurity Framework 2.0の6機能を、案件の確認観点として参照します。これは認証や準拠を宣言するものではなく、抜けを減らすための共通言語として使用します。

GV

決める

GOVERN

責任者、方針、契約、委託先、許容リスクを明確にします。

例:責任分担表、サービス一覧
ID

把握する

IDENTIFY

資産、データ、依存関係、脅威、影響を把握します。

例:データフロー、資産台帳
PR

守る

PROTECT

認証、最小権限、暗号化、秘密管理、安全な実装を設計します。

例:権限表、実装チェック
DE

気づく

DETECT

必要なログ、監視、アラート、異常の判断基準を決めます。

例:監視項目、ログ保持
RS

対応する

RESPOND

初動、封じ込め、調査、連絡、再発防止の流れを準備します。

例:連絡網、初動手順
RC

復旧する

RECOVER

バックアップの完全性、復旧順序、業務再開、事後確認を設計します。

例:復旧手順、試験記録

Application security

Web・アプリは、設計から運用まで確認。

OWASP ASVS 5.0を、アプリケーションのセキュリティ要件や確認項目を整理する参考にします。対象の重要度と予算に応じて、レビュー、自動検査、手動確認、外部試験を組み合わせます。

  1. 01要件・脅威データ、権限、攻撃面を整理
  2. 02実装認証、入力、秘密、依存関係
  3. 03検証レビュー、テスト、設定確認
  4. 04運用監視、更新、権限、復旧

Prototype vs production

プロトタイプと本番を、同じ扱いにしません。

以下は推奨設計の比較です。固定的な保証値ではなく、案件で確定する基準を示しています。

確認項目P0 数理プロトタイプP1 本番システム
目的実現可能性と指標の検証継続的な業務処理
データ量少量・匿名化・必要列を優先業務上必要な範囲を正式定義
環境短期の検証環境を分離開発・検証・本番の分離を検討
アクセス担当者を限定役割別権限、認証、棚卸し
外部AI原則として不要データを送らない設計から検討利用目的、対象、契約、設定、ログを合意
保持期間終了日を先に決める目的、法令、運用、バックアップを考慮
削除納品後の削除または継続利用を確認退会、契約終了、法定保存、バックアップを設計
復旧再作成可能性を評価復旧目標とバックアップ試験を決定

Shared responsibility

誰が守るかを、契約前に分ける。

クラウドを使えば自動的に安全になるわけでも、開発会社だけで全てを管理できるわけでもありません。お客様、ファイナイトフィールド、利用サービスの役割を分けます。

OUR SCOPE

設計・実装・開発運用で担うこと

契約範囲に応じて、システム側の対策と開発中のデータ取扱いを担当します。

  • データフローと権限設計
  • アプリケーションの安全な実装
  • 秘密情報と開発環境の管理
  • 合意した試験・レビュー
  • 保守範囲内の監視・更新・対応
契約で明確にする項目運用者監視時間バックアップ復旧作業問い合わせ終了時処理

AI & third parties

外部AIを、見えない委託先にしない。

生成AI、地図、メール、分析、通知、決済など、外部サービスへデータが渡る場合は、目的と範囲をデータフローに含めます。

MODE 00

送信しない

業務データを外部AIへ送信しない構成。通常のアルゴリズム、ローカル処理、匿名化済みの固定データなどで実装します。

最初に検討する選択肢
MODE A1

限定して送信

識別子を外し、必要な項目だけを、合意した目的とサービスへ送信します。送信内容を記録できるかも確認します。

匿名化・最小化が前提
MODE C2

承認範囲で送信

サービス条件、保存設定、契約、リージョン、再利用条件、権限を確認し、対象データを明記します。

個別のリスク判断が必要

EXTERNAL SERVICE CHECK

外部サービスごとに確認すること

  1. 01送るデータ項目・頻度・量
  2. 02目的処理・通知・分析など
  3. 03保存・再利用保持、学習、ログ
  4. 04場所・再委託国、リージョン、供給網
  5. 05停止・削除終了時の処理

Incident response

起きない前提ではなく、起きた時の動きを決める。

本番運用前に、対象事象、連絡先、初報方法、封じ込め、復旧、再発防止の責任を定義します。

01

検知・受付

監視、利用者連絡、サービス通知から事象を把握。

02

封じ込め

影響拡大を抑え、必要な証拠を保全。

03

分析・判断

対象データ、原因、影響、報告要否を確認。

04

連絡・対応

法令、契約、状況に基づき関係者へ連絡。

05

復旧・改善

安全を確認して復旧し、再発防止を反映。

本番前に確定緊急連絡先
本番前に確定対象事象
本番前に確定初報経路
案件で設計監視と対応時間
法令・契約に従う通知・報告

References

参照する考え方と、宣言しないこと。

法令・公的ガイドライン・オープンな標準を参考にしながら、案件に必要な管理策を選びます。参照することと、認証・完全準拠を宣言することは分けます。

JAPAN / PRIVACY

個人情報保護法・PPCガイドライン

安全管理措置、取扱規律、組織的・人的・物理的・技術的措置、外的環境の把握を確認する際の基礎にします。

公式資料を開く
RISK / MANAGEMENT

NIST Cybersecurity Framework 2.0

GOVERN、IDENTIFY、PROTECT、DETECT、RESPOND、RECOVERの6機能を、リスクと運用の抜けを確認する共通言語として参照します。

公式資料を開く
APPLICATION / VERIFICATION

OWASP ASVS 5.0

Web・アプリケーションのセキュリティ要件と検証項目を整理する際の参考にします。

公式資料を開く

このページだけでは、次を意味しません。

ISO/IEC 27001認証取得プライバシーマーク取得NIST CSF完全準拠OWASP ASVS認証事故が起きない保証全案件で同一の対策

FAQ

データの扱いについて、よくある質問。

診断やプロトタイプに本番データは必要ですか?

原則として、目的に必要な最小限の項目に絞り、匿名化・仮名化したサンプルで検証できるかを先に確認します。実データが必要な場合は、対象、保存場所、閲覧者、削除時期を事前に合意します。

外部の生成AIへデータを送信しますか?

外部AIの利用有無、送信対象、目的、保存条件を案件ごとに決めます。外部AIへ業務データを送信しない構成も選択できます。

データの保存国やリージョンは選べますか?

利用するクラウドや外部サービスの対応範囲内で、保存場所の要件を設計時に確認します。越境移転が関係する場合は、利用サービスとデータフローを明示します。

納品後のデータやソースコードはどうなりますか?

契約、運用方式、保守範囲に応じて、所有権、保管、アクセス、バックアップ、削除の責任分担を明確にします。

セキュリティ認証を取得していますか?

本ページは特定認証の取得を示すものではありません。採用する管理策と確認資料を案件ごとに定義し、必要に応じてお客様のチェックシートへ回答します。

インシデント発生時はいつ連絡されますか?

連絡先、対象事象、初報方法、更新頻度を本番運用前に決めます。実際の通知は法令、契約、事象の内容に基づいて行います。

医療・介護など要配慮情報を扱えますか?

データの必要性、法的要件、アクセス範囲、保存場所、ログ、削除、委託先を確認し、通常の業務データより厳しい設計が必要です。案件ごとに可否を判断します。

セキュリティ診断や脆弱性試験も依頼できますか?

対象と必要水準に応じて、設計レビュー、自動検査、手動確認、外部専門会社の利用を組み合わせます。範囲と成果物は見積時に明示します。

Next step

まず、送ってよいデータと、送らなくてよいデータを分けます。

Excelをそのまま送る前に、列名だけの資料や匿名化サンプルで相談できます。必要な管理と開発範囲を一緒に整理します。

数理化診断を始める データの扱いを相談する 機密情報は、送付方法を確認してからお送りください。
無料セキュリティ設計案を作る