これは何か
セキュリティ基本方針は、このプロジェクトとシステムで守るべき安全の考え方と決まりの大枠を示し、細かな規程・設計・手順の拠りどころにする成果物です。
権限設計表（SEC-002）や監査ログ要件一覧（SEC-004）のような具体的な成果物は、この方針にそって作ります。方針自体は短く、全員が読める長さにします。
なぜ作るか
- 安全についての判断が、人やチームによってばらばらにならないようにする
- 複数の会社（ベンダー）が関わっても、同じ決まりで作業できるようにする
- 決まりから外れる必要があるとき（例外）に、誰が認めるかをはっきりさせる
- 事故や疑わしいことが起きたとき、誰に知らせるかを全員が分かるようにする
誰が使うか・いつ作るか
- 作る人：セキュリティの責任者と担当。会社全体の方針があれば、それにそって作る
- 承認する人：プロジェクトの責任者、会社の安全の責任者など
- 使う人：プロジェクトの全員（社外の会社の担当を含む）
- 一般的には、プロジェクトの初期（設計を始める前）に作り、全員が読んだことを確かめ、必要に応じて見直します
- アステリア案件のセキュリティ基本方針の中身・承認者は、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
安全に関係する記載
- P-012 石井 稔 — セキュリティ責任者
- P-013 木村 亮 — AIガバナンス責任者
- システムに SYS-08 認証・ID基盤、SYS-10 AI開発エージェント、SYS-11 監視・ログ基盤がある
- マルチベンダー（Vendor A〜D の4社）
- AIは意思決定責任者ではない。セキュリティ例外承認は、AIへ最終委任しない事項の1つ
上の人物が方針を作る・承認するという記載は、正本にありません。未確定
主な項目
一般的には、次の項目を数ページにまとめます。
- 目的と適用範囲：何を守るための方針か。どのシステム・どの人（社外の会社の担当を含む）に適用するか
- 守るべき情報の分け方：情報を大切さで分ける（例：公開してよい／社内だけ／限られた人だけ）
- アクセスの原則：必要最小限、役割で権限を与える、本番のデータへの接近は申請と承認（08-02・08-05）
- 本人の確かめ方：ログインの仕組みの原則（08-01）
- 記録：誰が何をしたかを残し、守る（08-04）
- 開発と外部の会社：開発の環境・データの扱い、外部の会社に守ってもらうこと
- AIの利用：AIに渡してよい情報、AIに与える権限の考え方（AI-002）
- 例外：決まりから外れる必要があるときの申請と、認める人
- 事故・疑わしいことの連絡：誰に、どのように知らせるか
- 見直し：いつ、誰が見直すか
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 方針の一部
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
次の表は、方針の書き方を学ぶための例です。区分・決まりはすべて教材上の架空の例で、アステリア案件の方針ではありません。
| 情報の区分（教材上の例） | 例 | 扱いの決まり（教材上の例） |
|---|---|---|
| 公開 | 会社の案内 | 特になし |
| 社内 | 社内の手順書、会議の資料 | 社外の人に渡すときは、担当の承認を得る |
| 限定 | 顧客・社員の個人の情報、取引の条件 | 仕事に必要な人だけが見る。社外やAIに渡すときは、決まった手続きと承認を経る |
| 項目 | 決まり（教材上の例） |
|---|---|
| 申請する人 | 例外が必要な作業の担当 |
| 申請に書くこと | 何の決まりから外れるか、理由、期間、代わりにとる安全の対策 |
| 認める人 | 方針で決めた立場の人（AIは認める判断をしない） |
| 記録 | 申請と判断を例外の一覧に残し、期限が来たら見直す |
読み方
- 適用範囲に、社外の会社の担当が含まれているか
- 情報の区分と、区分ごとの扱いが書かれているか
- 例外を認める人と、例外の記録の仕方が書かれているか
- 事故や疑わしいことの連絡先が書かれているか
- AIに渡してよい情報と、渡してはいけない情報が分かるか
書き方
- 会社全体の方針や規程があれば、それを確かめる
- このプロジェクトで守るものと、関わる人（社外を含む）を洗い出す
- 大枠の決まりを、短く書く（細かな手順は別の成果物に書く）
- 例外の手続きと、連絡先を書く
- 承認を得て、全員に読んでもらい、読んだことを確かめる
- 決まりと実際の作業がずれていないか、定期的に見直す
何を書いてはいけないか
- 守られない細かな決まりを、大量に並べる（読まれなくなる）
- 例外の手続きがなく、実際には決まりが守られていない状態を放っておく
- 「適切に管理する」だけで、誰が何をするか分からない書き方
どこを見るか
- 適用範囲（社外の会社・AIを含むか）
- 情報の区分と扱い
- 例外の手続きと、認める人
- 連絡先
- 見直しの時期と、読んだことの確認
赤信号
- 方針はあるが、社外の会社の担当が読んでいない
- 例外の一覧がない、または期限のない例外が並んでいる
- AIの利用について何も書かれていない
- 事故の連絡先が、担当者の個人名だけ
よくある失敗
- 一般的なひな形をそのまま使い、このプロジェクトに合わない
- 方針を作ったあと、具体的な成果物（権限設計・ログの要件など）に落とし込まない
- 例外を口頭で認め、記録が残らない
関係するUnit・成果物・危機演習
- Unit：08-01 ログインできれば安全なのか、08-02 必要最小限の権限とは何か、08-04 誰が何をしたか残す、08-05 開発者は本番データを自由に見てよいのか
- 成果物：SEC-002 権限設計表、SEC-004 監査ログ要件一覧、SEC-005 セキュリティ評価報告書、AI-002 AIエージェント権限表
- 危機演習：CR10 重大な脆弱性が発見される（学習上の接続です。正式な対応関係ではありません）
AI WORKFLOW
AIは、方針と具体的な成果物のずれを探す下書きに役立ちます。
「このセキュリティ基本方針と権限設計表を比べ、①方針の決まりに合っていない可能性がある行、②方針に書かれているが、権限設計表で扱われていない決まり、を挙げてください。決まりの良し悪しは判断しないでください。」
REVIEW
- AIが挙げたずれを、人が元の文書で確かめたか
- AIが一般的な決まりを、このプロジェクトの決まりとして足していないか
- 方針を AI に渡してよいか（情報の区分）を、事前に確かめたか
人間が判断すること
- 方針の決まりと、適用範囲
- 例外を認めるか
- 事故や疑わしいことが起きたときの対応
セキュリティ例外承認は、AIへ最終委任しない事項です（正本の方針）。
いつ使うか
この教材では STAGE 08｜誰に何を許可するのか の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
プロジェクトの誰かが「これは安全上、やってよいのか」と迷ったとき、この方針を読めば判断の拠りどころと、相談する先が分かりますか？