システム開発セキュリティ規程

本規程は、当社の情報セキュリティマネジメントシステムの一環として制定したものであり、社外に開示する場合は「社外秘」として取り扱う。 当社の承諾なく複製・転載・再配布することを禁止する。

1. 目的

本規程は、当社が社内で開発・運用するシステムにおいて、設計段階で備えるべきセキュリティ機能および運用段階で遵守すべき管理ルールを定めることで、情報資産の安全を確保することを目的とする。 これにより、社内システム開発における最低限の統一基準を示し、事故や不具合を未然に防止する。

ただし、受託開発案件においては、当社規程よりも発注元の方針・指示が優先されるものとし、本規程は参考基準として位置づける。

2. 適用範囲

本規程は、当社に所属する以下システムの開発・運用セキュリティ担当者に適用する。

• 自社提供アプリケーション
• 顧客提供システムの受託開発案件（当社が開発を受託し、顧客が利用・提供するシステム）

3. 教育・周知

1. 管理者は、年1回以上の教育を受け、本規程に基づく統制を理解し実施すること。
2. 違反が発覚した場合は、再発防止教育を義務付ける。

4. アクセス・認証管理

4.1 特権的アクセス権(A.8.2)

1. 管理者権限アカウント（例：root, admin）は必要最小限とし、通常業務には利用しない。 通常業務は必ず一般権限のアカウントで行う。
2. 本番環境のサーバーで調査等を行う場合は、事前に作業内容・理由をまとめ、承認を得て実施する。
3. 特権アカウントの利用履歴（ログイン、操作記録）は必ず取得し、定期的に監査する。

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

1. サーバーやクラウド環境、データベース等へのアクセス権限は、職務に必要な最小限の者に限定する。

4.3 ソースコードアクセス(A.8.4)

1. ソースコード管理は バージョン管理システム（GitHub等）で一元管理する。
2. ソースコードへのアクセスは、最小権限の原則に基づき、業務上必要な人のみにアカウント付与・アクセス権限の限定を行う。
3. リポジトリは原則プライベートとし、公開が必要な場合は承認を得る。
4. 外部委託先へのアクセス付与は契約条項に基づき、利用終了後は速やかに削除する。
5. コードレビューを必須とし、直接の本番ブランチ（例：main/master）へのコミットは禁止する。

4.4 セキュリティを保った認証(A.8.5)

1. パスワード単独認証は避ける
   1. ユーザー名(メールアドレス)＋パスワードのみはNG。
   2. 最低でも MFA（2FA）必須。
2. 推奨する安全な認証方式
   1. パスキー認証（FIDO2, WebAuthn）
   2. Googleアカウント / MicrosoftアカウントによるSSO
   3. OAuth2 / OIDC などの標準規格
3. セッション管理
   1. セッションタイムアウト、トークンの有効期限を設定
   2. Cookie セキュリティ属性（HttpOnly, Secure, SameSite）
4. 認証情報の安全な保管
   1. パスワードは平文禁止、PBKDF2 / bcrypt / Argon2 でハッシュ化
   2. APIキー・トークンは暗号化ストアで管理

5. 運用基盤と環境管理

5.1 容量・能力の管理（A.8.6）

1. システムは予測される利用量を考慮し、容量・性能を定期的に監視する。
2. 容量不足・性能劣化の兆候がある場合は、速やかにスケールアップ/スケールアウト等を検討する。

5.2 マルウェアに対する保護（A.8.7）

1. 開発・運用に利用するソフトウェアやライブラリは、正規の配布源から入手し、改ざんや不正なコード混入がないことを確認する。
2. 依存関係や取得したソフトウェアの完全性は固定・検証し、不審な変更が検出された場合は利用を停止する。
3. マルウェアや不正プログラムの混入を防ぐため、技術的な仕組み（自動検知、スキャン、監視等）を導入し、定期的に確認を行う。

5.3 技術的な脆弱性の管理（A.8.8）

1. 開発に使用するライブラリ・フレームワークは常に最新の安定版を利用する。
2. Dependabotや脆弱性診断ツールにより、既知の脆弱性を検出・修正する。
3. 修正困難な場合は、リスクを評価し代替策を講じる。

5.4 構成管理（A.8.9）

1. システム構成はInfrastructure as Code（IaC）等でコード化し、変更はレビュー・承認を経て反映する。
2. 本番環境の設定変更は必ず承認を経て行う。

5.5 情報の削除（A.8.10）

1. 個人情報や機密データを削除する際は、アプリケーション機能または安全な削除方式を用いる。

5.6 データマスキング（A.8.11）

1. テスト環境で個人情報を利用する場合は、必ず匿名化・マスキングを行う。
2. 実データを用いる必要がある場合は、開発責任者の承認を得る。
3. 個人情報の利活用を行う場合は、個人情報保護法に基づき、仮名化もしくは匿名化を行う必要がないかを確認し、必要に応じて実施する。

5.7 データ漏えい防止（A.8.12）

1. 機微情報は必ず暗号化して保存、送受信する。
2. 機微情報のログ出力(クレジットカード番号、氏名・住所などのログへの出力)を禁止する。

5.8 情報のバックアップ（A.8.13）

1. 重要データは定期的にバックアップを取得し、リストア手順を定期的に検証する。
2. バックアップデータは暗号化して保存し、アクセス制御を行う。

5.9 冗長性（A.8.14）

1. 本番環境は障害発生時に事業継続できるよう、クラウドサービス等の冗長構成を基本とする。
2. 単一障害点（SPOF）が存在しないよう設計・レビューを行うこと。 ただし、システムの重要度や予算等に応じて、短時間の停止が許容される場合は、必要最小限の構成（例：開発環境のNATゲートウェイを単一構成とするなど）も認める。
3. 冗長化を行わずSPOFを許容する場合は、その理由と影響範囲を文書化し、システムの責任者の承認を得て関係者間で共有すること。

5.10 ログ取得（A.8.15）

1. システムはアクセスログ・操作ログを可能な限り取得する。
2. ログにはユーザーID、操作内容、実行日時、接続元情報を含める。

5.11 監視活動（A.8.16）

1. 不正アクセスや異常を検知するために監視システムを導入する。
2. 自動検知できない場合は、管理者が定期的にサンプルレビューを行う。

5.12 クロックの同期（A.8.17）

1. サーバ・システムは信頼できるNTPサーバと同期し、ログの時刻整合性を保つ。

5.13 特権的なユーティリティプログラムの使用（A.8.18）

1. OSやDB等の特権的ユーティリティは、正当な業務に限って利用する。
2. 利用記録を残し、証跡を保存する。

5.14 運用システムへのソフトウェア導入（A.8.15）

1. 本番環境へのソフトウェア導入は、テスト環境での動作確認後に実施する。
2. 本番環境におけるソフトウェアの変更（リリース、利用しているソフトウェアの変更やバージョンアップなど）は、変更が失敗したときに切り戻し（ロールバック）ができるようにする。

6. ネットワーク管理

6.1 ネットワークセキュリティ（A.8.20）

1. システム外部からの通信やシステム間通信は、WAFやファイアウォール、セキュリティグループ等により不要な通信を遮断する。
2. 管理用ネットワークは、利用者ネットワークや外部公開ネットワークと分離する。

6.2 ネットワークサービスのセキュリティ（A.8.21）

1. 公開するサービスは必要最小限に限定し、不要なポートやサービスは停止する。
2. 提供するネットワークサービスは、既知の脆弱性に対して適切に保護・更新する。

6.3 ネットワークの分離（A.8.22）

1. 開発・テスト環境と本番環境は分離し、相互の接続を禁止する。
2. 管理用ドメイン（例：admin.example.com）は、公開用ドメインとは別に設ける。

6.4 ウェブフィルタリング（A.8.23）

1. システム内部（サーバ・コンテナ等）から外部ネットワークへの通信は、NATやプロキシを経由させ、必要最小限の接続先ドメインに限定する。

6.5 暗号の利用（A.8.24）

1. 開発するシステムへのネットワーク通信は TLS 等の暗号化を必須とし、平文通信は許可しない。
2. データベースやストレージに保存する情報は、必要に応じて暗号化を適用する。
3. 暗号鍵は安全に保管・更新・廃棄し、不正利用を防ぐ。

7. 開発ライフサイクル管理

7.1 セキュリティを考慮したライフサイクル（A.8.25）

1. 企画・設計段階からセキュリティ要件を考慮し、設計レビューで確認する。

7.2 アプリケーションセキュリティの要求事項（A.8.26）

1. システム要件には認証・暗号化・監査ログなどのセキュリティ要件を含める。
2. 機微情報の取り扱いは必ず要件化する。

7.3 セキュアアーキテクチャ（A.8.27）

1. システム設計は分離・冗長化・最小権限を基本とし、セキュリティレビューを経る。

7.4 セキュアコーディング（A.8.28）

1. 開発者は安全なコーディング規約を遵守し、静的解析やコードレビューで確認する。
2. 入力値検証・エラーハンドリング・暗号化APIの適切利用を徹底する。

7.5 セキュリティテスト（A.8.29）

1. 開発・受入時に脆弱性診断、セキュリティテストを行い、結果を記録する。
2. 重大な脆弱性が解消されるまでリリースしてはならない。

7.6 外部委託開発（A.8.30）

1. 委託先への委託開発はPOL-014_サプライヤー管理規程の規定に従う。

7.7 環境分離（A.8.31）

1. 開発・テスト・本番環境は物理的または論理的に分離する。
2. 開発・テスト環境には、一般の利用者（社外・顧客等）が直接接続できないようにする。
3. 各環境にて利用する秘密認証情報（パスワード、秘密鍵など）は、環境ごとに異なった文字列を利用する。

7.8 変更管理（A.8.32）

1. 本番環境への変更は必ず申請・承認を経て行う。
2. 変更内容は記録し、影響範囲をレビューしてから実施する。

7.9 テスト用情報（A.8.33）

1. テストデータは匿名化・マスキングした情報を利用する。
2. 実データ利用は受託元や責任者の承認を得て、廃棄した際の証跡を残すこと。

7.10 監査時のテスト環境保護（A.8.34）

1. システム監査やぜい弱性診断を行う場合は、原則、本番環境と構成を同じくした、異なる環境で実施する。やむを得ず本番環境にて行う場合は、システムの運用に影響がないよう十分に注意する。

8. 操作手順書の管理（A.5.37）

1. 重大な影響を及ぼす作業（バックアップ取得・復元、暗号化設定、重要サービス再起動、データ移行等、「機密性」「完全性」「可用性」に影響を与える作業）は、操作・リカバリー手順書を作成し、レビューをうけること。
2. 手順書の所在とCI/CD・監視のURL等は、ソースコードのトップドキュメントに一覧化して明示すること（例：/README.md あるいは /docs/OPERATIONS.md に「リンク一覧」節を設ける）。
3. 手順書は手順変更時などに常に改訂し、最新状態を維持すること。

改訂履歴

改定日	版	改定内容	承認
2025-09-12	-	初版制定	-
2026-06-10	1.0	GitHubリポジトリ（airs/isms）へ移行。改訂履歴章を文書末尾へ移動し後続章番号（節番号含む）を繰り上げ。POL-014への参照を相対リンクへ置換	加藤匡邦