セキュリティ対策

ProcessMindのセキュリティ対策

発効日：2026年9月14日

本書は、ProcessMind B.V.が顧客データの機密性、完全性および可用性を保護するために維持する技術的および組織的措置（「TOM」）について説明します。ProcessMindは、多層防御のアプローチを採用し、ネットワークおよびインフラストラクチャから、ID、認可、データ分離、暗号化、監視およびソフトウェア開発に至るまで、あらゆるレベルで複数の独立したセキュリティ層により顧客データを保護します。これらの措置は、データ処理付属書、プライバシーポリシーおよびSaaSホスティングポリシーを補足します。ProcessMindは、これらの措置を少なくとも年1回見直し、更新します。

顧客データが第三者に販売もしくは共有されること、または第三者自身の目的のために使用されることは一切ありません。

1. インフラストラクチャのセキュリティ

**1.1 クラウドプラットフォーム。**ProcessMindは、EU内（ドイツ、フランクフルト、eu-central-1）のAmazon Web Services（AWS）のみでホストされています。AWSは、ISO 27001、ISO 27017、ISO 27018、SOC 1/2/3およびPCI DSSの認証を維持しています。全リストについては、AWSコンプライアンスプログラムをご覧ください。

**1.2 サーバーレスアーキテクチャ。**ProcessMindのアプリケーションロジックは、AWS LambdaおよびAWSマネージドサービス上で実行されます。ProcessMindは、お客様が管理する長期間稼働するアプリケーションサーバーを運用しないため、オペレーティングシステムのパッチ適用およびサーバーの強化に関する作業の大部分が不要になります。

**1.3 ネットワーク境界。**ProcessMindは、データベースおよびネットワーク制御のためにAWS VPCを維持しています。Aurora PostgreSQLはインターネットへの送信経路のないプライベートサブネットで稼働し、パブリックアクセスはできません。また、VPCフローログが有効になっています。ProcessMindは、デフォルトではアプリケーションのLambda関数をVPC内に配置しません。Lambdaは、IAMおよびSecrets Managerによる認証を使用し、TLS経由のAWS RDS Data APIを通じてAuroraに接続します。

**1.4 コンテンツ配信およびエッジ制御。**お客様向けウェブサイト、フロントエンドSPAおよび公開リソースのトラフィックは、Amazon CloudFrontを通じて配信されます。すべてのCloudFrontディストリビューションでは、TLS 1.2（2021）を最低TLSポリシーとして適用しています。ウェブサイトおよびフロントエンドSPAのディストリビューションでは、HTTP Strict Transport Security（HSTS）、Content Security Policy（CSP）、frame-ancestors 'none'、X-Frame-Options: DENY、X-Content-Type-Options、リファラーポリシーおよび権限ポリシーを含むセキュリティレスポンスヘッダーも追加しています。公開リソースのディストリビューションでは、CloudFront Origin Access Controlを使用してオリジンバケットを非公開にしています。お客様向けAPIトラフィックは、Amazon API Gatewayを通じて別途処理されます。HTTPSのリクエスト／レスポンストラフィックは専用APIサブドメイン上のHTTP APIを通じて配信され、リアルタイムのクライアント接続は専用WebSocketサブドメイン上の別個のAPI Gateway WebSocket APIを通じて配信されます。

**1.5 環境の分離。**本番環境と開発環境では、別々のAWSアカウント、データベースおよびインフラストラクチャスタックを使用しています。開発者の認証情報では、本番環境の顧客データにアクセスできません。

2. データの暗号化

**2.1 転送中の暗号化。**クライアントとProcessMindのサービス間で送信されるすべてのデータは、TLS 1.2以上を使用して暗号化されます。お客様向けエンドポイントはHTTPS経由で公開されます。ProcessMindが直接作成するS3バケット、SNSトピックおよびSQSキューでは、SSLのみのアクセスを強制しています。RDS Data APIを介したデータベースアクセスおよびその他のAWSサービス呼び出しには、HTTPS/TLSを使用します。

**2.2 保存データの暗号化。**Aurora PostgreSQLは、自動キーローテーションを有効にした、お客様が管理するAWS KMSキーを使用して保存時に暗号化されます。ProcessMindが直接作成する顧客データ用および運用用のS3バケット（アップロード、リソースおよびアクセスログ用バケットを含みます）では、お客様が管理するKMSキーを使用します。ProcessMindが直接作成するCloudWatchロググループ、SNSトピックおよびSQSキューでも、お客様が管理するKMSキーを使用します。SSTが管理するウェブサイトおよびフロントエンドのオリジンバケットでは、お客様が管理するKMSキーではなく、AWS管理のS3サーバー側暗号化（SSE-S3／AES-256）を使用します。

**2.3 キー管理およびシークレット。**データベース暗号化キーはAWS KMSを通じて一元管理され、キーへのアクセスは最小権限の原則に従ったIAMポリシーによって管理されます。データベース認証情報はAWS Secrets Managerに保存されます。Auroraのマスターシークレットおよび制限付きアプリケーションユーザーのシークレットは、30日ごとに自動ローテーションされます。本番環境のキーおよびシークレットがソースコードに保存されることはありません。開発専用の認証情報は本番環境から分離されています。一部のAWS／CDK／SST管理の補助リソースについては、サービスまたはフレームワークでお客様が管理するキーの設定が公開されていない場合、引き続きAWS管理の暗号化を使用します。

3. データの分離および保管場所

**3.1 テナントの分離。**各顧客テナントには、専用の分離されたデータベースインスタンスが割り当てられます。データベースレベルで顧客データが他のお客様のデータと混在することはありません。共有メタデータ（アカウント記録、請求情報、ユーザーとテナントの対応関係など）は、厳格なアクセス制御を備えた別個のマルチテナントデータベースに保存されます。テナントおよび組織の範囲に限定された共有テーブルは、リクエストごとのデータベースコンテキストを通じて適用されるPostgreSQLの行レベルセキュリティ（RLS）ポリシーによっても保護されています。

**3.2 データの保管場所。**データベース、ファイルのアップロード、バックアップおよびクエリ結果を含むすべての顧客データは、EU（ドイツ、フランクフルト）内にのみ保存されます。特定の処理活動（たとえば、AIモデル処理または決済処理）のためにEEA域外に所在する再委託先を利用する場合、データ移転はデータ処理補遺に記載された適切な移転メカニズムによって保護され、当該再委託先およびその処理場所は再委託先一覧に記載されます。

**3.3 データの保持および削除。**保持および削除の期間は、データ処理付属書第6項に定められています。お客様は、アプリケーションを通じて、またはProcessMindに連絡することで、いつでもデータを削除できます。バックアップコピーは、該当するバックアップの保存期間（第7.1項）の満了に伴い削除されます。

4. アイデンティティおよびアクセス管理

**4.1 認証。**ProcessMindは、Microsoft Entra ID（Azure AD）、Google OAuth 2.0/OIDCおよびLinkedIn OAuth 2.0/OIDCを介したシングルサインオン（SSO）をサポートしています。ProcessMindは依拠当事者として機能し、ユーザーパスワードを保存しません。多要素認証はアイデンティティプロバイダーによって適用されます。たとえば、組織がMicrosoft Entra ID（Azure AD）を接続する場合、その組織独自のMFAおよびアクセスに関するポリシーが適用されます。

**4.2 セッション管理。**ブラウザーセッションでは、SameSiteおよびSecureフラグを設定した安全なHttpOnly Cookieを通じて送信される、署名付きJSON Web Token（JWT）を使用します。認証済みリクエストごとにトークンの署名を検証します。

**4.3 認可モデル。**ProcessMindは、コアアプリケーションAPIについて、API Gatewayのネイティブオーソライザーに依存しません。ビジネスロジックの実行前にセッション状態およびテナント範囲を検証する、共通のLambdaハンドララッパーによって認可を適用します。公開ルートは、未認証フロー、Webhook、イベント取り込みおよびCORSプリフライト用として明示的に許可リストに登録されています。外部APIエンドポイントでは、専用の認証ハンドラを使用します。顧客データへのアクセスは、認証済みのテナントまたは組織のコンテキストに限定されます。

**4.4 最小権限。**内部システムでは、最小権限の原則に従います。フレームワークで正確な範囲指定が可能な場合、IAMロールの範囲は必要最小限のリソースに限定されます。一部のSST／CDK生成ロールでは、バインディングおよび実行時の運用のために、より広範なマネージドポリシーまたはインラインポリシーを使用します。これらのケースは審査され、可能な場合はリソース単位で範囲を限定し、明示的な例外として記録されます。

**4.5 従業員のアクセス制御。**内部システムへの従業員のアクセスは、SSOおよび必須のMFAを備えたActive Directoryを通じて管理されます。ロールベースアクセス制御（RBAC）により、顧客データへのアクセスは、知る必要のある権限を有する担当者に限定されます。アクセス権は定期的に見直されます。

5. ログ記録、監視および監査

5.1 集中ログ記録。 HTTP APIアクセスログおよびWebSocketアクセスログは、構造化されたJSONフィールドを使用して有効化されており、Amazon CloudWatch Logsに書き込まれ、1年間保持されます。これらのアクセスロググループは、顧客管理のAWS KMSキーで暗号化されます。アプリケーションログは、顧客管理のAWS KMSキーで暗号化されたAmazon CloudWatchロググループに集約され、10年間保持されます。監査ロググループおよびテレメトリロググループも別途、顧客管理のAWS KMSキーで暗号化され、10年間保持されます。Aurora PostgreSQLエンジンログのエクスポートグループは1週間保持されます。

5.2 ログに記録される情報と記録されない情報。 ProcessMindは、HTTP APIおよびWebSocketのアクセスイベント（リクエスト時刻、リクエスト識別子、ルートまたはパス、レスポンスステータスおよびレイテンシ）を記録します。アクセスログには、呼び出し元の送信元IPアドレスまたはユーザーエージェントは含まれません。ProcessMindは、認証イベント、非同期処理の失敗経路、および補助的なLambdaアプリケーションのアクティビティも、集中管理されたCloudWatchロググループに記録します。VPCフローログは有効化されています。ProcessMindは現在、ウェブサイト、フロントエンドSPA、または公開リソースのディストリビューションでCloudFront標準アクセスログを有効化していません。

**5.3 監視およびアラート。**CloudWatchのアラームおよびダッシュボードは、システムの健全性、デッドレターキューおよびセキュリティに関連する障害を監視します。非同期処理の障害は暗号化されたデッドレターキューに送られ（保存期間は14日間、サムネイルおよび検索インデックスのキューは2日間）、DLQアラームは調査のためのSNS通知を発します。さらに、ProcessMindは、フロントエンドのエラーをリアルタイムで追跡し、パフォーマンスを監視し、セッションをリプレイするためにSentryを使用します。セッションリプレイは、エラーが発生したセッションについてのみ記録され、リプレイではテキスト、フォーム入力およびメディアがマスキングまたはブロックされます。SentryのデータはEU（フランクフルト）で取り込まれ、ProcessMind利用データ（ブラウザーエラー、パフォーマンストレース、デバイスメタデータおよびマスキングされたリプレイ記録）に限定されます。Sentryはサブプロセッサー一覧に記載されています。

**5.4 ログの保護。**ログは、専用のアクセス制御されたCloudWatchロググループに保存され、保存時に暗号化されます。本番環境と開発環境のログは、環境およびアカウントの境界によって分離されています。

6. 自動化された管理策の検証および脆弱性管理

**6.1 ProcessMindが実施すること。**ProcessMindは、複数の業界ルールパック（AWS Solutions、NIST 800-53およびPCI DSSを含みます）を使用して、インフラストラクチャの合成およびデプロイのワークフローの一環としてcdk-nagを実行します。スタックごとのレポートが生成され、インフラストラクチャ変更管理の一環として審査されます。検出事項は、修正済み、受容したリスク、または計画された改善としてトリアージされます。

**6.2 例外の管理方法。**抑制は、フレームワークで可能な場合は中央レジストリに記録され、影響を受けるスタックに範囲が限定され、書面による正当化を必要とします。スタックにインライン抑制が含まれる場合は、そのスタックと併せて文書化されます。検出事項が是正された場合、対応する抑制は更新または削除されます。ProcessMindは、抑制を審査からの包括的な除外として扱いません。

**6.3 ProcessMindが現在実施していないこと。**ProcessMindは、インフラストラクチャ管理策に関する重要な例外を追跡し、審査しています。主な例外は以下のとおりです。

アプリケーションのLambdaは、デフォルトではVPC内に配置されません。IAMおよびSecrets Managerによる認証を使用し、TLS経由のRDS Data APIを通じてAuroraに接続します
サービスのいずれの部分もAWS WAFで保護されていません。AWS WAFはAPI Gateway HTTP APIsをサポートしておらず、その他のエントリーポイントもWAFで保護されていません（WebSocket接続では短期間有効なHMACトークンを使用し、決済関連の地域制限は決済システムで適用されます）。静的コンテンツの配信にもCloudFront標準アクセスログは設定されていません
データベースの復旧は、別個のAWS BackupプランまたはAurora Enhanced Monitoringではなく、Auroraの自動バックアップおよび特定時点への復旧に依存しています
変更可能なバケットについて、リージョン間のS3レプリケーションまたはS3 Object Lockは設定されていません
一部のAWS/CDK/SST管理下の補助リソースでは、サービスが顧客管理の代替手段を提供していない場合、AWS管理の暗号化またはより広範な生成IAMポリシーが使用されています

抑制対象の完全な登録簿はインフラストラクチャコードとともに管理されており、請求に応じて提供されます。cdk-nagルールパックの使用は、エンジニアリング上の統制検証であり、HIPAA、NISTまたはPCI DSSへの準拠に関する外部認証、監査意見または法的証明ではありません。

**6.4 依存関係の管理。**ソフトウェアの依存関係について、既知の脆弱性がないか継続的に監視しています。重大および高深刻度の脆弱性は、7日以内を目標に修正します。依存関係は定期的なサイクルで更新されます。

**6.5 セキュアソフトウェア開発ライフサイクル（SDLC）。**ProcessMindは、ソフトウェア開発において多層防御のアプローチを採用しています。本番環境へのすべての変更は、デプロイ前に複数の独立した自動検証レイヤーを通過する必要があります。

**静的解析および型安全性：**TypeScriptのstrictモードおよびESLintにより、コンパイル時に型の正確性、null安全性、およびセキュリティに関連するコーディングパターンを適用します。
**AI支援コードレビュー：**AI支援分析により、プルリクエストに対する追加のレビュー観点を提供し、自動テストを補完して、セキュリティリスク、ロジックエラーおよび規約からの逸脱を特定します。
**単体テストおよび統合テスト：**包括的なVitestテストスイートにより、開発環境の実際のAWSリソースに対して、ビジネスロジック、データアクセスパターン、APIの動作およびエラー処理を検証します。
**エンドツーエンドテスト：**Playwrightベースのブラウザテストにより、認証、データアップロード、プロセスモデリング、シミュレーションおよびマルチテナント分離を含む重要なユーザーワークフローを検証します。
インフラストラクチャのコンプライアンススキャン：cdk-nagにより、変更のたびに複数のコンプライアンスフレームワークに照らしてインフラストラクチャ・アズ・コードを検証します。
**依存関係の脆弱性スキャン：**自動化された依存関係監査により、既知の重大および高深刻度の脆弱性が本番環境に到達することを防止します。

人によるレビューは、行単位のコード検査ではなく、アーキテクチャ、セキュリティ境界および設計レベルの判断に重点を置きます。構造上の変更、セキュリティに関わる変更またはインフラストラクチャの変更がある場合は、自動検証に加えて、明示的な人による承認が必要です。

すべての検証レイヤーは、アプリケーションおよびインフラストラクチャのmainブランチへの変更に対する必須のマージゲートとして、CIを通じて適用されます。ウェブサイトのコンテンツおよび静的アセットのリリースは、アプリケーションのCIゲートではなく、デプロイ時のチェック（法的文書が最新であることの自動チェックを含みます）を伴う、別途文書化されたリリースプロセスに従います。本番環境に対する緊急修正ではCIゲートを迂回できますが、その場合、24時間以内にパイプライン全体を実行し、インシデント後のレビューを実施する必要があります。

7. バックアップおよび災害復旧

**7.1 自動バックアップ。**Amazon Auroraは、7日間の保持期間で継続的な自動バックアップを実行します。バックアップは、ソースデータベースと同じ顧客管理KMSキーを使用して暗号化されます。

**7.2 ポイントインタイムリカバリ。**Auroraは、バックアップ保持期間内の任意の秒時点へのポイントインタイムリカバリに対応しており、データ破損または誤削除が発生した場合に迅速な復元を可能にします。

**7.3 S3の耐久性およびバージョニング。**ファイルアップロードおよび運用上の成果物は、99.999999999%（イレブンナイン）の耐久性を提供するAmazon S3に保存されます。復旧およびロールバックを可能にするため、アップロード用バケットおよびリソースバケットではバージョニングが有効になっています。ウェブサイトおよびフロントエンドのデプロイ用バケットは再現可能なビルド成果物であり、バックアップシステムとして扱われません。ProcessMindは現在、リージョン間S3レプリケーションを有効にしていません。

**7.4 事業継続。**災害復旧手順は文書化され、定期的にテストされています。概要は、災害復旧、事業継続およびインシデント対応文書に記載されています。アーキテクチャは、eu-central-1リージョン内のAWSマネージドサービスに依存しており、AWSはこれらを複数のアベイラビリティーゾーンにわたって運用しています。Auroraクラスターは現在、単一のライターインスタンスで稼働しているため、データベースの復旧は、同一リージョン内のスタンバイではなく、自動バックアップおよび特定時点への復旧に依存します。Auroraのバックアップ、S3の耐久性、デッドレターキュー、およびソースから再構築する静的アセットは、復旧戦略の一部です。

8. インシデント対応

**8.1 インシデント通知。**セキュリティインシデント（DPAで定義）の発生時、ProcessMindは、不当な遅延なく、かつ可能な場合にはインシデントを認識してから72時間以内に、影響を受ける顧客に通知します。

**8.2 インシデント対応。**ProcessMindは、特定、封じ込め、根絶、復旧およびインシデント後のレビューを対象とする、文書化されたインシデント対応手順を維持しています。概要は、災害復旧、事業継続およびインシデント対応文書に記載されています。インシデントから得られた教訓は、セキュリティ管理策およびプロセスに反映されます。

**8.3 連絡。**インシデント通知には、インシデントの性質および範囲、影響を受けたデータのカテゴリー、インシデントを封じ込めるために講じた措置、および顧客に推奨する対応が含まれます。

9. 組織的措置

**9.1 情報セキュリティ管理。**ProcessMindは、ISO 27001の原則に沿った情報セキュリティ管理システムを維持しています。ProcessMindは、ISO 27001認証およびSOC 2 Type II保証報告書に向けた認証取得方針を選定していますが、正式な認証プロセスはまだ開始していません。

**9.2 セキュリティ意識。**顧客データへのアクセス権を有するすべての人員は、セキュリティ意識向上のための研修を受けます。セキュリティのベストプラクティスは、オンボーディング、開発ワークフローおよび運用手順に組み込まれています。

**9.3 ベンダーおよびサブプロセッサーの管理。**サブプロセッサーは、本書に記載された基準と同等のデータ保護基準を契約上遵守する義務を負います。ProcessMindは公開サブプロセッサー一覧を維持し、新たなサブプロセッサーを起用する少なくとも30日前に通知します。サブプロセッサーは、コンプライアンスについて年1回審査されます。

**9.4 機密保持。**顧客データの処理を許可されたすべての人員は、書面による機密保持義務を負います。

10. コンプライアンスおよび認証

フレームワーク／規格	状況
GDPR（EU一般データ保護規則）	遵守済み
EUデータレジデンシー（ドイツ、フランクフルト）	適用済み
AWSインフラストラクチャ認証（ISO 27001、SOC 2、PCI DSS）	AWSを通じて継承
ISO 27001（ProcessMind）	計画中 — 認証取得の方針を選定済み。正式なプロセスは未開始
SOC 2 Type II（ProcessMind）	計画中 — 認証取得の方針を選定済み。正式なプロセスは未開始
自動化されたインフラストラクチャ管理策の検証（`cdk-nag` AWS Solutions、HIPAA Security、NIST 800-53 R4/R5、PCI DSS 3.2.1、Serverlessに対応）	認証ではなく、エンジニアリング管理策の検証として実施済み
国際移転に関する標準契約条項（SCC）	実施済み（DPAを参照）
データ処理付属書（DPA）	公開済み

cdk-nagルールパックを使用していることは、ProcessMindがHIPAA、NISTまたはPCI DSSに関する正式な認証を受けていること、または独立した監査を受けていることを意味しません。これらのルールパックは、インフラストラクチャ設計を検証し、ギャップを明示的に追跡するためのエンジニアリング上のガードレールとして使用されています。

セキュリティ、コンプライアンスに関するご質問、または監査報告書や記入済みセキュリティ質問票などの文書の請求については、support@processmind.comまでお問い合わせください。