ダークモード

エンジニア向けセキュリティガイドライン ​

関連方針: 技術的セキュリティ方針、アクセス制御方針

関連管理策: A.8 技術的管理策

1. 目的 ​

本ガイドラインは、{{組織名}}の開発者・運用者（エンジニア）が遵守すべき技術的なセキュリティルールを定めることを目的とする。

2. 適用範囲 ​

本ガイドラインは、以下の者に適用する：

  • ソフトウェア開発者
  • インフラエンジニア
  • システム運用担当者
  • データベース管理者
  • セキュリティ担当者
  • 上記の業務を行う委託先要員

3. アクセス管理 ​

3.1 特権アクセスの管理 (A.8.2) ​

原則 ​

  • 特権アカウントは必要最小限の人員にのみ付与する
  • 日常業務には一般ユーザーアカウントを使用する
  • 特権アカウントの使用はログに記録される

遵守事項 ​

  • [ ] 特権アカウントの共有禁止
  • [ ] 特権操作は承認を得てから実施
  • [ ] 特権アカウントには強固な認証を設定（MFA 必須）
  • [ ] 不要になった特権は速やかに返上

3.2 情報へのアクセス制限 (A.8.3) ​

  • 最小権限の原則に基づきアクセス権を設定する
  • 業務上必要な範囲のみにアクセス権を付与する
  • 定期的にアクセス権をレビューし、不要な権限を削除する

3.3 ソースコードへのアクセス (A.8.4) ​

  • ソースコードリポジトリへのアクセスは承認制とする
  • 本番環境のコードは直接編集しない
  • コードレビューなしでのマージを禁止する
  • センシティブな情報（API キー、パスワード等）をコードに含めない

3.4 認証の実装 (A.8.5) ​

認証機能を実装する際の要件：

  • [ ] パスワードは bcrypt/Argon2 等の安全なアルゴリズムでハッシュ化
  • [ ] パスワードの平文保存・平文送信の禁止
  • [ ] ログイン試行回数の制限（アカウントロック）
  • [ ] セッション管理の適切な実装
  • [ ] 多要素認証（MFA）のサポート

3.5 特権ユーティリティの使用 (A.8.18) ​

  • 特権ユーティリティ（root 権限ツール等）の使用は必要最小限とする
  • 使用履歴を記録する
  • 使用後は速やかにログアウト・終了する

4. 開発セキュリティ ​

4.1 セキュア開発ライフサイクル (A.8.25) ​

要件定義 → 設計 → 実装 → テスト → デプロイ → 運用
    ↓         ↓       ↓        ↓         ↓        ↓
セキュリティ セキュリティ セキュア   セキュリティ セキュリティ 脆弱性
要件定義    設計      コーディング テスト    チェック    監視

4.2 セキュリティ要求事項の定義 (A.8.26) ​

開発開始時に以下を定義すること：

  • [ ] 認証・認可の要件
  • [ ] データ保護の要件（暗号化、マスキング等）
  • [ ] 監査ログの要件
  • [ ] コンプライアンス要件（GDPR、個人情報保護法等）

4.3 セキュアアーキテクチャ (A.8.27) ​

設計原則 ​

  • 多層防御（Defense in Depth）
  • 最小権限の原則
  • フェイルセキュア（障害時は安全側に倒す）
  • 信頼境界の明確化

遵守事項 ​

  • [ ] 信頼境界を越える通信は暗号化
  • [ ] 入力値の検証は信頼境界で実施
  • [ ] センシティブなデータは暗号化して保存

4.4 セキュアコーディング規約 (A.8.28) ​

入力値検証 ​

全ての入力は信頼しない
  → サーバー側で必ず検証
  → クライアント側検証は UX 目的のみ
  • [ ] SQL インジェクション対策（プリペアドステートメント使用）
  • [ ] XSS 対策（出力エスケープ）
  • [ ] CSRF 対策（トークン検証）
  • [ ] パストラバーサル対策
  • [ ] コマンドインジェクション対策

禁止事項 ​

  • eval() 等の動的コード実行
  • ハードコードされた認証情報
  • 自作の暗号アルゴリズム
  • 非推奨・脆弱なライブラリの使用

4.5 セキュリティテスト (A.8.29) ​

リリース前に以下のテストを実施すること：

  • [ ] 静的解析（SAST）の実施
  • [ ] 依存ライブラリの脆弱性スキャン
  • [ ] 動的解析（DAST）の実施（Web アプリケーションの場合）
  • [ ] 侵入テスト（重要システムの場合）

4.6 外部委託開発の管理 (A.8.30) ​

外部委託先に開発を依頼する場合：

  • [ ] 本ガイドラインの遵守を契約に含める
  • [ ] セキュリティ要件を明確に伝達
  • [ ] 成果物のセキュリティレビューを実施
  • [ ] ソースコードの権利関係を明確化

5. 環境管理 ​

5.1 開発・テスト・本番環境の分離 (A.8.31) ​

開発環境 ─→ テスト環境 ─→ ステージング環境 ─→ 本番環境
  │              │                │               │
  │              │                │               │
本番データ禁止   本番データ禁止     マスキング済み    実データ

遵守事項 ​

  • [ ] 各環境のアクセス権を分離
  • [ ] 開発・テスト環境に本番データを使用しない
  • [ ] 本番環境への直接変更を禁止
  • [ ] 環境間の認証情報を分離

5.2 テストデータの管理 (A.8.33) ​

  • 本番データをテストに使用する場合は必ずマスキング・匿名化
  • 個人情報を含むテストデータは使用後に削除
  • テストデータの生成ツールの使用を推奨

5.3 監査テスト時の保護 (A.8.34) ​

監査・ペネトレーションテスト実施時：

  • [ ] 実施範囲・日時を事前に合意
  • [ ] 本番環境への影響を最小化
  • [ ] テスト用アカウント・データは終了後に削除

6. インフラセキュリティ ​

6.1 ネットワークセキュリティ (A.8.20, A.8.21, A.8.22) ​

ネットワーク分離 ​

  • DMZ、内部ネットワーク、管理ネットワークを分離
  • セグメント間の通信はファイアウォールで制御
  • 不要なポートは閉じる

遵守事項 ​

  • [ ] ファイアウォールルールは最小権限で設定
  • [ ] 外部公開サービスは必要最小限
  • [ ] VPN 経由でのみ内部ネットワークにアクセス

6.2 ウェブフィルタリング (A.8.23) ​

  • 業務上不要なカテゴリの Web サイトへのアクセスを制限
  • マルウェア配布サイト、フィッシングサイトをブロック
  • 例外申請は承認制

6.3 暗号化の実装 (A.8.24) ​

通信の暗号化 ​

  • [ ] 外部通信は TLS 1.2 以上を使用
  • [ ] 内部通信も可能な限り暗号化
  • [ ] 自己署名証明書は本番環境で使用しない

保存データの暗号化 ​

  • [ ] センシティブなデータは暗号化して保存
  • [ ] 暗号鍵は適切に管理（鍵管理サービス使用推奨）
  • [ ] 暗号アルゴリズムは AES-256 等の標準を使用

7. 運用セキュリティ ​

7.1 変更管理 (A.8.32) ​

本番環境への変更は以下のプロセスに従うこと：

  1. 変更申請の提出
  2. 影響分析・リスク評価
  3. 承認者による承認
  4. テスト環境での検証
  5. 変更の実施
  6. 結果の確認・記録

7.2 ソフトウェア導入 (A.8.19) ​

  • 承認されたソフトウェアのみ導入可能
  • 導入前にセキュリティリスクを評価
  • ライセンスの適切な管理

7.3 容量・能力の管理 (A.8.6) ​

  • リソース使用状況を監視
  • 閾値を設定してアラート通知
  • 定期的な容量計画のレビュー

8. 保護対策 ​

8.1 マルウェア対策 (A.8.7) ​

  • [ ] 全サーバー・端末にウイルス対策ソフトを導入
  • [ ] 定義ファイルの自動更新を有効化
  • [ ] リアルタイムスキャンを有効化
  • [ ] 定期的なフルスキャンを実施

8.2 脆弱性管理 (A.8.8) ​

脆弱性情報の収集 ​

  • {{脆弱性情報源}} を定期的に確認
  • 使用しているソフトウェアの脆弱性情報を監視

パッチ管理 ​

深刻度対応期限
緊急{{期限}}
高{{期限}}
中{{期限}}
低{{期限}}

8.3 構成管理 (A.8.9) ​

  • [ ] 本番環境の構成を文書化
  • [ ] 構成変更は変更管理プロセスに従う
  • [ ] セキュリティベースラインからの逸脱を検知

8.4 データ漏えい防止 (A.8.12) ​

  • [ ] DLP ツールの導入を検討
  • [ ] 外部への大量データ転送を監視
  • [ ] 機密データの外部送信を制限

9. データ管理 ​

9.1 情報の削除 (A.8.10) ​

  • 保持期限を超えたデータは確実に削除
  • 削除は復元不可能な方法で実施
  • 削除の証跡を記録

9.2 データマスキング (A.8.11) ​

  • テスト・開発目的で本番データを使用する場合はマスキング
  • マスキングルールを文書化
  • マスキング済みデータからの逆引きが不可能なことを確認

10. 監視・ログ ​

10.1 ログ取得の実装 (A.8.15) ​

以下のイベントをログに記録すること：

  • [ ] 認証成功・失敗
  • [ ] 認可の成功・失敗（アクセス拒否）
  • [ ] 管理者操作
  • [ ] データの作成・変更・削除
  • [ ] システムエラー・例外

ログの要件 ​

  • タイムスタンプ（UTC または JST を統一）
  • ユーザー識別子
  • イベント種別
  • 対象リソース
  • 結果（成功・失敗）
  • 送信元 IP アドレス

10.2 監視の実装 (A.8.16) ​

  • [ ] 不正アクセスの検知
  • [ ] 異常なトラフィックパターンの検知
  • [ ] リソース枯渇の検知
  • [ ] アラートの適切なエスカレーション

10.3 時刻同期 (A.8.17) ​

  • 全システムで NTP による時刻同期を設定
  • 時刻同期の状態を監視
  • ログのタイムスタンプ形式を統一

11. セキュリティチェックリスト ​

11.1 開発開始時チェックリスト ​

  • [ ] セキュリティ要件を定義した
  • [ ] 脅威モデリングを実施した
  • [ ] セキュア設計のレビューを受けた
  • [ ] 使用するライブラリの脆弱性を確認した

11.2 リリース前チェックリスト ​

  • [ ] コードレビューを完了した
  • [ ] 静的解析を実施し、重大な問題を修正した
  • [ ] 依存ライブラリの脆弱性スキャンを実施した
  • [ ] セキュリティテストを実施した
  • [ ] センシティブな情報がコードに含まれていないことを確認した
  • [ ] ログ出力が適切に実装されている
  • [ ] エラーメッセージが過剰な情報を含まないことを確認した

11.3 運用開始後チェックリスト ​

  • [ ] 監視・アラートが正常に動作している
  • [ ] ログが適切に収集されている
  • [ ] バックアップが正常に取得されている
  • [ ] 脆弱性スキャンを定期的に実施している
  • [ ] アクセス権を定期的にレビューしている

12. 関連文書 ​

改訂履歴 ​

版日付変更内容承認者
1.0{{発効日}}初版作成{{承認者}}