情報セキュリティと機密保持

8.1 概要と目的

本章は、ProviderによるProjectVIEW ERPプラットフォームの提供を規律する情報セキュリティおよび機密保持の義務を定める。サブスクリプション期間を通じて、Customer Data、プラットフォームの完全性、およびProviderの専有知的財産を保護するセキュリティアーキテクチャ、認証管理、暗号化基準、ネットワーク防御、脆弱性管理手順、および機密保持条項を定める。

Providerの情報セキュリティ管理システム（ISMS）はIT部門によって維持され、ISO/IEC 27001:2022に整合している。本章は、技術的セキュリティ管理策を扱うものであり、第7章（データ保護およびプライバシー）に記載されたプライバシー固有の措置、および第4章（サービスサポートおよび運用）に記載された運用支援のセキュリティ措置を補完する。

DANAOS Web Enterpriseは、プレゼンテーション層（Webブラウザ）からアプリケーション層（アプリケーションサーバー）、データ層（データベースサーバー）に至るアプリケーションスタックのすべての層にセキュリティ機構を組み込み、各Customer専用のプライベートな主権環境内で機密性、完全性、可用性（C.I.A.トライアド）をエンドツーエンドで確保する。

8.2 範囲

本章が対象とする事項:

• (a) プラットフォームのアプリケーションセキュリティ: DANAOS Web Frameworkに組み込まれた認証、認可、セッション管理、入力検証、およびセキュアコーディングの実践。
• (b) インフラセキュリティ: 各CustomerのAzureホスト型主権環境に適用されるネットワーク分離、ファイアウォール設定、侵入検知、DDoS防御、およびWeb Application Firewall（WAF）制御。
• (c) データベースセキュリティ: SQL Serverデータベースインスタンスに対するアクセス制御、暗号化（保存時および転送時）、監査ログ、権限管理、接続監視。
• (d) 運用セキュリティ: 脆弱性管理、侵入テスト、パッチ管理、変更追跡、およびセキュリティインシデント対応（個人データ以外のインシデント。個人データ侵害は§7.15に準拠）。
• (e) ソースコードセキュリティ: Providerの独自コードベースを規律する知的財産保護、セキュア開発ライフサイクル、Gitベースのバージョン管理、およびコードレビューの実務。
• (f) 機密保持義務: 相互の機密保持約束、情報分類、開示制限、および存続条項。

8.3 セキュリティ標準とフレームワーク

Providerのセキュリティプログラムは、以下の標準、フレームワーク、および指針に基づいて構築されている。

ISO/IEC 27001:2022 NIST CSF 2.0 OWASP Top 10（2021） CIS Azure Foundations Benchmark NIST SP 800-63B-4 Azure Well-Architected Framework

8.4 アプリケーションセキュリティ

DANAOS ProjectVIEW ERPプラットフォームは、システムの機密性と完全性を確保するため、アプリケーション層に以下のセキュリティ機構を備える。これらの管理策は各Customerインスタンスに適用され、STY（Users & Roles Management）モジュールを通じてCustomerのシステム管理者が設定可能である。

8.4.1 認証管理

8.4.2 認可とアクセス制御

プラットフォームのUsers & Roles Managementモジュール（STY）は、複数のレベルできめ細かなロールベースアクセス制御（RBAC）を適用する。

• (a) モジュールレベル: ユーザーには、そのロール割り当てに基づき、モジュール全体（例: PV_07 HRMS–Payroll、PV_08 Accounting）へのアクセスを許可または拒否する。
• (b) 機能レベル: モジュール内の個々の機能（例: 購買発注の作成、請求書の承認、給与の閲覧）は、それぞれ独立して権限付与される。
• (c) フィールドレベル: レコード内の機微な項目（例: 給与額、銀行口座、国民ID）は、特定のロールに対して非表示または読み取り専用にできる。
• (d) レコードレベル: 行レベルのセキュリティにより、組織階層に基づいて表示範囲を制限する（例: プロジェクトマネージャーは割り当てられたプロジェクトのみ閲覧可能、地域マネージャーは自地域のみ閲覧可能）。
• (e) 職務分掌: 競合ロール検知により、1人のユーザーが職務分掌上の競合を生じるロール（例: 起票者と承認権限者）を兼任することを防止する。STYモジュールは、検知された競合を管理者に通知し、ポリシーベースの制限を適用する。
• (f) 一意のユーザーID: すべてのユーザーアカウントには一意の識別子が割り当てられる。共有アカウント／汎用アカウントは禁止される。すべての操作は監査証跡を通じて個々のユーザーに追跡可能である。
• (g) 制限付きリモートアクセス: システム管理者は管理コンソールからユーザーごとにリモートアクセスを制御する。アクセスは随時許可または取り消し可能である。

8.4.3 セッションセキュリティ

• (a) セッショントークン: 認証時に暗号学的にランダムなセッショントークンが生成される。セッショントークンは、セッションハイジャックを防止するため、ユーザーのIPアドレスおよびユーザーエージェント文字列に紐付けられる。
• (b) セッション無効化: セッションは、パスワード変更、アカウント停止、明示的なログアウト、またはアイドルタイムアウトの満了時に無効化される。
• (c) 同時セッション制御: ユーザーアカウントごとの同時アクティブセッション数に設定可能な上限を設ける。既定: ユーザーにつき1つのアクティブセッション（最後のログインが優先されるポリシー）。

8.4.4 入力検証と出力エンコーディング

• (a) サーバー側検証: ユーザー入力はすべて、ホワイトリスト方式の検証を用いてサーバー側で検証される。クライアント側検証は、あくまで使い勝手向上のためのものとし、セキュリティ管理策としては扱わない。
• (b) パラメータ化クエリ: すべてのデータベース操作は、SQLインジェクションを防止するため、パラメータ化クエリ（プリペアドステートメント）を使用する。ユーザー入力からの動的SQL構築は、Providerのセキュアコーディング標準により禁止される。
• (c) 出力エンコーディング: ブラウザにレンダリングされるすべてのデータは、クロスサイトスクリプティング（XSS）を防止するため、文脈に応じてエンコードされる（必要に応じてHTML、JavaScript、URL、CSSのエンコーディングを使用）。
• (d) Content Security Policy（CSP）: HTTP応答ヘッダーには、XSSおよびデータ注入攻撃を軽減するための厳格なContent Security Policyが含まれる。

8.5 インフラセキュリティ

各CustomerのProjectVIEW ERPインスタンスは、Microsoft Azure上の専用のプライベートな主権環境に展開される。以下に記載するインフラセキュリティ管理策はテナントごとに適用され、CIS Azure Foundations BenchmarkおよびAzure Well-Architected Security Pillarに整合している。

8.5.1 ネットワークセキュリティ

• (a) Network Security Groups（NSG）: 各仮想マシンは、明示的な許可／拒否ルールを備えたステートフルファイアウォール機能を提供するNSGによって保護される。既定ポリシー: 受信はすべて拒否し、必要なサービスポートのみ許可する。
• (b) Web Application Firewall（WAF）: Azure WAFはアプリケーション層の前面に配置され、SQLインジェクション、XSS、CSRF、リクエストスミアリング攻撃を含むOWASP Top 10の脅威から保護する。
• (c) DDoS Protection: Azure DDoS Protection StandardはすべてのCustomer環境で有効化され、ボリュメトリック、プロトコル、およびアプリケーション層の攻撃を自動検知とインライン是正により軽減する。
• (d) ネットワーク分離: データ層、アプリケーション層、管理層は別々のサブネットに展開され、層間通信はNSGルールによって制御される。データベースサブネットはインターネットから直接アクセスできない。
• (e) VPNおよびプライベート接続: Customerがサイト間接続を必要とする場合（例: オンプレミスのActive Directoryとの統合）、Azure VPN GatewayまたはExpressRouteをIPSec/IKEv2暗号化付きで提供する。
• (f) DNSセキュリティ: Azure Private DNSゾーンを使用し、DNSベースのデータ流出を防止する。公開DNSレコードは、レジストラが対応している場合、DNSSECで保護される。

8.5.2 コンピュートセキュリティ

• (a) オペレーティングシステムのハードニング: すべての仮想マシンはMicrosoft Windows Server 2022を実行し、CIS Windows Server 2022 Benchmarkに従ってハードニングされる。不要なサービス、ポート、機能は無効化される。
• (b) パッチ管理: セキュリティパッチは、(i) Critical/High CVEについて72時間以内、(ii) Medium CVEについて30暦日以内、(iii) Low CVEについて次回の保守ウィンドウまでに適用する。パッチは本番展開前にStaging Environmentでテストされる。
• (c) マルウェア対策: クラウドネイティブなエンドポイント保護（Microsoft Defender for Cloud）をすべての仮想マシンで有効化し、リアルタイムスキャン、行動分析、自動是正を行う。
• (d) ホストベース侵入検知: Azure Security Centreは、すべてのVMにおけるファイル整合性、疑わしいプロセス実行、異常なシステムコールを監視する。

8.5.3 IDとシークレットの管理

• (a) Azure Key Vault: すべての暗号鍵、証明書、接続文字列、およびサービス資格情報はAzure Key Vaultに保管され、アクセスはAzure RBACおよびKey Vaultアクセス ポリシーによって制御される。
• (b) マネージドID: 可能な場合は、サービス間認証にAzure Managed Identitiesを使用し、アプリケーション設定に保存された資格情報を不要にする。
• (c) シークレットローテーション: すべてのサービスアカウント資格情報およびAPIキーに対して、自動シークレットローテーションポリシーを適用する。最大ローテーション期間: 90暦日。

8.6 データベースセキュリティ

このプラットフォームのデータ層は、Microsoft Windows Server 2022 上に展開された Microsoft SQL Server 2022（Standard または Enterprise Edition） で稼働します。以下の、CIS SQL Server 2022 Benchmark に整合したデータベース固有のセキュリティ管理策を適用しています。

8.6.1 アクセスおよび認証

• (a) データベース認証: SQL Server は、主たる認証方式として Windows 認証モード（Active Directory 連携）を使用します。Mixed モード認証は、顧客が明示的に必要性を認め、承認しない限り無効です。
• (b) アプリケーションのパスワード: アプリケーションレベルのデータベース資格情報には、パスワード構成ポリシーに準拠した強力なパスワードを使用し、秘密情報ローテーション計画（§8.5.3）に従って更新します。
• (c) 既定アカウント: すべての既定システムアカウント（例: 「sa」）は DBA により適切に保護されます。既定パスワードはプロビジョニング直後に変更され、不要な既定アカウントは無効化または削除されます。
• (d) 接続制御: データベースインスタンスへの接続は制御および監視されます。接続を確立できるのは、認可されたアプリケーション層サービスと指定された DBA 要員のみです。接続文字列は Azure Key Vault（§8.5.3）に保管されます。
• (e) 接続可能性: ネットワークレベルの管理により、データベース接続はアプリケーション層サブネットおよび認可された管理エンドポイントのみに制限されます。データベースへのインターネットからの直接接続は禁止されています。

8.6.2 権限管理

• (a) 最小権限およびロール: データベースユーザーアカウントには、その機能に必要な最小限の権限とロールのみを付与します。最小権限の原則を適用し、定期的に見直します。
• (b) システム権限: 明示的に必要とされ承認されない限り、すべての「system」権限はユーザーアカウントから削除します。特権操作には、MFA を有効にした専用の別 DBA アカウントが必要です。
• (c) 職務分掌: データベース管理権限は、アプリケーション開発権限から分離されています。開発者には本番データベースへのアクセス権を付与しません。
• (d) 権限レビュー: データベース権限割り当てを四半期ごとにレビューし、未使用または過剰な権限は取り消します。レビュー結果は文書化され、監査に提供可能です（§7.11）。

8.6.3 暗号化

• (a) Transparent Data Encryption（TDE）: TDE は本番およびステージングのすべてのデータベースインスタンスで有効化され、AES-256 暗号化を用いてデータファイル、ログファイル、および tempdb を暗号化します。TDE 証明書はバックアップを取得し、Azure Key Vault に保管します。
• (b) バックアップ暗号化: すべてのデータベースバックアップ（フル、差分、およびトランザクションログ）は、Azure Key Vault で管理される顧客専用の暗号化キーを用いて AES-256 で暗号化されます。
• (c) 列レベル暗号化: 顧客のデータ分類ポリシーで必要とされる場合、極めて機微な項目（例: 国民識別番号、銀行口座番号）に対して列レベル暗号化（Always Encrypted）を利用できます。

8.6.4 監査およびログ記録

• (a) 監査ログ: SQL Server Audit は、(i) すべての DDL 操作（スキーマ変更）、(ii) 特権ユーザーの活動、(iii) 認証失敗試行、(iv) データエクスポートおよびバルクコピー操作、(v) 権限変更を捕捉します。監査ログは改ざん検知可能な保管先に書き込まれます。
• (b) ログ保管期間: データベース監査ログは、オンラインで最低 12 か月、アーカイブ保管で 24 か月保持されます。保管期間は GDPR、UAE PDPL、および適用される業界標準の要件を満たします。
• (c) 変更追跡: SQL Server Change Tracking と Change Data Capture（CDC）を有効化し、コンプライアンスおよび監査目的でデータ変更の完全な一覧を提供します。
• (d) DBA のリモートアクセス: リモートによるデータベース管理は、暗号化チャネルと多要素認証を用いて指名された個人に限定されます。すべての DBA セッションは、コマンドレベルまで完全に追跡可能な監査証跡とともに記録されます（§7.8.3）。

8.7 脆弱性管理

プロバイダーは、NIST CSF の Identify（ID.RA）および Protect（PR.IP）機能に整合した継続的な脆弱性管理プログラムを運用します。

8.7.1 評価スケジュール

8.7.2 是正期限

ゼロデイ脆弱性: プラットフォームの技術スタックに影響し、実際に悪用されているゼロデイ脆弱性については、プロバイダーは緊急の軽減策（例: WAF ルール、ネットワーク分離、仮想パッチ）を 24 時間以内に適用し、恒久パッチは Critical の是正 SLA に従って適用します。

8.8 セキュリティ監視およびインシデント対応

8.8.1 監視

プロバイダーは、以下のコンポーネントを使用して 24 時間 7 日間のセキュリティ監視体制を運用します。

• (a) SIEM: クラウドネイティブの Security Information and Event Management（Microsoft Sentinel）が、インフラストラクチャ、アプリケーション、データベースのすべてのレイヤーからログを集約します。相関ルールと機械学習による検知により、異常なパターンを特定します。
• (b) AIOps: AI 駆動の運用ツールにより、パフォーマンス指標、認証パターン、データアクセス量に対する予測的異常検知を行い、セキュリティ関連の逸脱がインシデントに発展する前に早期特定を可能にします。
• (c) 脅威インテリジェンス: SIEM は、既知の攻撃シグネチャおよび侵害指標を検知するため、リアルタイムの脅威インテリジェンスフィード（Microsoft Threat Intelligence、業界特化 IOC）を統合します。
• (d) User and Entity Behaviour Analytics（UEBA）: ユーザーおよびサービスアカウントについてベースライン行動プロファイルを設定します。異常なログイン地点、通常と異なるデータアクセスパターン、権限昇格の試みなどの逸脱が検知されると、自動アラートが発報されます。

8.8.2 セキュリティインシデント対応

個人データを含まないセキュリティインシデントは、本項に基づき管理します。個人データの漏えいは、§7.15に従います。インシデントが後日、個人データを含むものと分類された場合には、下記の措置に7.15の漏えい通知手続を加えて適用します。

8.8.3 顧客通知

プロバイダーは、次のいずれかに該当するセキュリティインシデントについて顧客に通知します。(i) 顧客データへの実際の、または疑いのある不正アクセスが発生した場合。(ii) プラットフォームの可用性または完全性に重大な影響を与える場合。または

• (iii) 顧客環境に関連する法執行機関との関与を伴う場合。通知は、インシデントの深刻度および §7.15.1 に定める侵害通知 SLA に整合した期限内に行われます。

8.9 セキュア開発ライフサイクル（SDLC）

プロバイダーは、OWASP の Software Assurance Maturity Model（SAMM）および Microsoft の Security Development Lifecycle（SDL）に整合したセキュア SDLC を運用します。

• (a) 脅威モデリング: 新機能および重要な変更は、設計段階で脅威モデリングを実施します。STRIDE 手法で脅威を特定し、DREAD でリスクの優先順位を付けます。
• (b) セキュアコーディング標準: 開発者は、入力検証、出力エンコーディング、認証、セッション管理、エラー処理、暗号化を対象とするプロバイダーのセキュアコーディング標準（OWASP Secure Coding Practices に基づく）に従います。
• (c) Static Application Security Testing（SAST）: 自動 SAST は、コードのコミットごとに実行されます。High/Critical の所見がある場合は、解決されるまでビルドが停止されます。
• (d) Dynamic Application Security Testing（DAST）: DAST は、各本番展開の前にステージング環境に対して実行されます。スキャンは OWASP Top 10 および ASVS Level 2 の管理策を対象とします。
• (e) Software Composition Analysis（SCA）: すべてのサードパーティ依存関係について、既知の脆弱性（CVE）およびライセンス準拠を各ビルド時にスキャンします。未修正の Critical/High CVE を持つコンポーネントはブロックされます。
• (f) コードレビュー: 本番コードの変更はすべて、Master ブランチへのマージ前にピアレビューと承認が必要です。セキュリティに関わる変更（認証、暗号化、アクセス制御ロジック）は、指定されたセキュリティチャンピオンによるレビューが必要です。
• (g) バージョン管理: Master/Client/Working ブランチモデルを用いた Git ベースのバージョン管理（§4.7）。すべてのコミットは署名され、個々の開発者に追跡可能です。Master への force-push は禁止されています。

8.10 ソースコード保護

プロバイダーのソースコードは proprietary intellectual property であり、以下の保護対象となります。

• (a) アクセス制限: ソースコードリポジトリにアクセスできるのは、認可されたプロバイダーの開発要員のみです。別途ソースコードエスクロー契約を締結しない限り、顧客要員はソースコードにアクセスできません。
• (b) ソースコードエスクロー: 顧客から要請があれば、プロバイダーは信頼できる第三者のエスクロー代理人とソースコードエスクロー契約を締結します。開放条件には通常、プロバイダーの支払不能、本フレームワークへの重大な違反、または適切な後継製品を伴わないプラットフォームの提供終了が含まれます。
• (c) シンクライアントアーキテクチャ: プラットフォームはシンクライアント型の Web アプリケーションとして動作します。プロプライエタリなソースコード、コンパイル済みバイナリ、またはアプリケーションロジックはクライアントデバイスに配布されません。すべてのアプリケーション処理は、顧客の主権環境内のサーバー側で実行されます。
• (d) 難読化: ブラウザーに配信されるクライアント側の JavaScript および CSS は、圧縮および難読化されます。本番展開ではソースマップは公開されません。
• (e) オープンソース義務なし: プロバイダーは、オープンソースコンポーネントの使用によってプロプライエタリなソースコードを開示する義務が生じないようにします（例: コピーレフトライセンスの汚染）。すべてのオープンソースコンポーネントは、採用前にライセンス互換性を確認します。

8.11 秘密保持義務

8.11.1 情報分類

当事者間で交換されるすべての情報は、以下の区分に従って分類されます。

8.11.2 相互の秘密保持誓約

各当事者は、相手方に対し、以下を行うことを約します。

• (a) 開示当事者のすべての秘密情報を機密として保持し、開示当事者の事前の書面による同意なく第三者へ開示しないこと。
• (b) 本フレームワークに基づく義務の履行または権利行使の目的に限り、秘密情報を使用すること。
• (c) 秘密情報の開示を、本フレームワークの目的上その情報を知る必要がある自己の従業員、代理人、または再委託先に限定し、それらの者には本規定と同等以上に厳格な秘密保持義務を課すこと。
• (d) 開示当事者の秘密情報の保護については、自らの機密情報に適用するのと同程度の注意を払うこと。ただし、いかなる場合も合理的な注意義務を下回らないこと。
• (e) Confidential Information の実際のまたは疑われる無権限の開示もしくは使用があった場合は、直ちに開示当事者に通知する。

8.11.3 除外事項

秘密保持義務は、以下の情報には適用されません。

• (a) 受領当事者の責によらず公知となっている、または公知となった情報。
• (b) 開示時点で既に受領当事者が知っていたことが、書面記録により示される情報。
• (c) 秘密情報に依拠せず、受領当事者が独自に開発した情報。
• (d) 開示制限なく第三者から合法的に取得した情報。
• (e) 適用法令、規制、または裁判所命令により開示が必要な情報。ただし、受領当事者は、開示当事者に対して速やかに書面通知を行い（法的に許容される範囲で）、保護的取扱いを得るためのあらゆる प्रयासに協力するものとします。

8.11.4 存続

本項に定める秘密保持義務は、本フレームワークの終了または満了後 5 年（5） 間存続します。ただし、営業秘密については、適用法令上それが営業秘密である限り保護されます。

8.12 アクセス削除

8.12.1 システムアクセス削除

プロバイダー従業員の役割が変更された場合、または雇用が終了した場合、すべてのシステムアクセスは以下の期限内に削除されます。

• (a) 非自発的退職またはセキュリティ上の懸念: すべてのシステム資格情報、VPN アクセス、Key Vault 権限、および物理施設へのアクセスを直ちに失効（1 時間以内）します。
• (b) 計画退職: アクセスは最終勤務日に失効します。プロバイダー所有デバイスはすべて返却され、ワイプされます。
• (c) 役割変更: 新しい役割の権限要件を反映するよう、1 営業日以内にアクセスを調整します。以前の役割による過剰権限は削除されます。

8.12.2 アプリケーションアクセス削除

顧客のエンドユーザーの役割が変更されるか、顧客組織を離れる場合:

• (a) 顧客の責任: STY モジュール内のユーザーアカウントを無効化または変更する責任は、顧客のシステム管理者（または Champion）が負います。
• (b) プロバイダー支援: 顧客がプロバイダー支援を必要とする場合（例: 一括無効化、緊急ロックアウト）、P2 サービスリクエスト（§4.3）を起票し、適用される SLA に従って処理します。
• (c) 休眠アカウント検知: プラットフォームは、90 暦日を超えてログイン活動がないアカウントをフラグ付けします。フラグ付けされたアカウントは、レビューおよび無効化の可能性について顧客管理者に報告されます。

8.13 プロセス登録簿

次の表は、本章で規定する契約上および運用上のプロセスを列挙したものである。各プロセスには、固有識別子、発動条件、担当者、承認者、期待成果、および関連条項への参照を割り当てる。

8.14 プロセスフロー図

以下の図は、リスクアセスメントから継続監視およびインシデント対応までの情報セキュリティライフサイクルを示します。

① ISMS リスクアセスメント → ② セキュリティアーキテクチャおよび管理策 → ③ セキュア開発および展開

▼

④ 脆弱性管理 → ⑤ 継続監視（SIEM / AIOps） → ⑥ アクセス制御およびレビュー

▼

⑦ インシデント検知および対応 → ⑧ 事後レビューおよび改善 → ⑨ コンプライアンス監査および認証

継続ループ: ステージ⑨（監査および認証）は、ISMS の継続的改善サイクル（Plan-Do-Check-Act）を通じてステージ①（リスクアセスメント）にフィードバックされます。ステージ④～⑦は、毎週の自動スキャンとリアルタイムの SIEM 監視によって継続的に運用されます。年次の侵入テストおよび認証監査により、独立した保証を提供します。