設計対象:

開発・検証・本番の各環境におけるセキュリティ統制と、アクセス権限管理のルールを決定する。

具体例:

• 環境別のアクセス権限レベル(開発環境は誰がアクセスできるか、本番環境はどう制限するか)
• 認証方式(SSO、多要素認証の適用範囲)
• ネットワークセグメンテーション(開発環境から本番環境への直接アクセスを禁止するか)
• 本番データの取り扱いルール(マスキング、匿名化の要否)
• 環境間のデータ移動ポリシー(本番データを開発環境にコピーする際の手続き)

設計原則:

• 最小権限の原則: 各開発者・チームに必要最小限の権限のみを付与する
• 職務分離: 開発者が本番環境に直接デプロイできない仕組みを設け、承認フローを経由させる
• 環境分離: 開発・検証・本番環境を物理的・論理的に分離し、相互の影響を防ぐ
• 監査証跡の確保: 誰がいつどの環境にアクセスしたか、ログとして記録・保管する
• 定期的な権限見直し: 異動・退職時やプロジェクト終了時に速やかに権限を削除する

文書化の推奨表現:

• 環境別セキュリティマトリクス: 各環境のセキュリティレベルとアクセス制御ルールを一覧表にまとめる
• 権限管理フロー図: 権限申請・承認・削除のフローを図示する
• セキュリティ基準の明記: 準拠すべきセキュリティ標準(CIS Benchmarks等)を明示する
• 例外処理の規定: 緊急時の本番アクセスなど、例外的な対応が必要な場合の手続きを定義する

設計対象:

開発で使用するツール・SaaSサービスの選定・承認プロセスと、コスト管理の仕組みを決定する。

具体例:

• 使用を許可するツール・サービスの一覧(GitHub、Slack、AWS、Datadogなど)
• 新規ツール導入の申請・承認フロー
• ライセンス管理(誰が何のライセンスを持っているか、更新タイミング)
• 認証情報の保管場所(パスワード管理ツール、シークレット管理サービス)
• クラウドコストの予算配分と監視(環境別・チーム別の予算上限)
• コストアラートの設定(予算の80%超過時に通知など)

設計原則:

• 承認された技術の利用: 勝手に外部サービスを導入せず、承認プロセスを経て利用する
• コスト可視化: 誰がどのリソースでどれだけコストを使っているか、タグ付けで可視化する
• 予算管理の徹底: 環境別・チーム別に予算を設定し、定期的にレビューする
• 認証情報の集中管理: パスワードやAPIキーを個人のPCに保存せず、専用ツールで管理する
• 定期棚卸: 使われていないツール・ライセンス・リソースを定期的に見直し、削減する

文書化の推奨表現:

• ツール一覧と承認状況: 使用中のツール・サービスを一覧化し、承認者・利用開始日を記録する
• コスト管理ダッシュボード: 予算と実績を可視化するダッシュボードのURLや設定方法を記載する
• 申請フローの図示: 新規ツール導入の申請から承認までのフローを図にまとめる
• 認証情報管理ガイド: どの認証情報をどこに保管するか、アクセス権限の管理方法を明記する

設計対象:

法令・規格への準拠要件を特定し、遵守のための体制とプロセスを決定する。

具体例:

• 準拠すべき法令・規格(個人情報保護法、GDPR、PCI DSS、SOC2など)
• 定期監査の計画(年1回の外部監査、四半期ごとの内部監査)
• セキュリティ教育・訓練の実施(新メンバーへの初期研修、年1回の全体研修)
• インシデント対応手順(セキュリティ事故発生時の報告ルート、初動対応)
• 変更管理プロセス(本番環境への変更は承認が必要、変更履歴の記録)
• ドキュメント管理(設計書・手順書のバージョン管理、レビュー・承認フロー)

設計原則:

• 法令準拠の徹底: 該当する法令・規格を漏れなく特定し、遵守策を講じる
• 証跡の確保: 監査に耐えられるよう、承認・実施・レビューの記録を残す
• 継続的改善: 監査結果やインシデントから学び、ガバナンス体制を継続的に改善する
• 教育の実施: ルールを作るだけでなく、チーム全体に周知・教育し、実効性を確保する
• 責任の明確化: 各統制項目の責任者と問い合わせ先を明確にする

文書化の推奨表現:

• コンプライアンスチェックリスト: 準拠すべき要件を項目別に整理し、対応状況を管理する
• ガバナンス体制図: 承認者・実施者・監査者の役割と関係性を図示する
• 監査計画とスケジュール: 年間の監査スケジュールと監査項目を明記する
• 教育計画: 実施すべき教育・訓練の内容と頻度を定義する
• 問い合わせ先一覧: 各統制項目の担当部署・担当者と連絡先を記載する