あなたがフォームを公開します。誰かがそれを記入します。名前、メールアドレス、場合によっては生年月日や病状が、どこかのデータベースに保存されます。
次に何が起こるのでしょうか？誰がそれを見ることができるのでしょうか？どのように保存されるのでしょうか？使用しているプラットフォームが侵害された場合はどうなるのでしょうか？
フォームを作成する多くの人は、何か問題が発生するまでこれらの質問をしません。この投稿は、その前にそれらを尋ねること、そしてその答えがどのように見えるべきかを知ることについてです。
ここで区別する価値のある関連リスクがあります：ランダムなオンラインツールに機密ファイルをアップロードすること—PDF圧縮、変換、結合—は別の問題ですが、関連する問題であり、オンラインで決して処理すべきでない5種類のファイルで詳しく説明しました。この記事は、制御できないツールにファイルを渡すリスクについてです。この記事は、フォームプラットフォーム自体—あなたの回答者が提出するものを収集、保存、管理するソフトウェア—のリスクについてです。
このページで
なぜフォームデータがターゲットになるのか
フォームは、どのビジネスにおいても最も高密度なデータ収集ポイントの一つです。単一の受付フォームで、名前、連絡先情報、保険情報、医療問題の説明を一度に収集することができます。
その集中度が、フォームを攻撃者にとって魅力的にし、そのデータを収集・保存するプラットフォームがセキュリティを真剣に考える必要がある理由です。
リスクは抽象的ではありません。誤った設定のフォームは、正しいURLを持つ誰にでも提出物を公開することができます。適切なアクセス制御のないプラットフォームは、不満を持つ従業員や1つのアカウントを侵害した外部の攻撃者がすべてにアクセスできることを意味します。保存中のデータが暗号化されていない場合、ストレージシステムが侵害された場合にデータが回復可能です。
良いニュースは、適切なセキュリティアーキテクチャがこれらすべてを処理することです。問題は、あなたが使用しているプラットフォームがそれを持っているかどうかです。
実際に重要なセキュリティスタック
セキュリティドキュメントは難解なことがあります。ここでは、あなたのデータにとって重要な主要な部分が実際に何を意味するのかを説明します。
転送中および保存時の暗号化
転送中とは、データがユーザーのブラウザからサーバーに移動する際に暗号化されることを意味します。これはTLS（HTTPSの背後にある技術）が提供します。TLS 1.2およびTLS 1.3は現在の標準です。古いバージョンには既知の脆弱性があり、使用すべきではありません。
保存時とは、データがストレージ（データベース、バックアップ、ファイルシステム）に保存されているときに暗号化されることを意味します。標準はAES-256であり、世界中の政府や金融機関で使用されている対称暗号化アルゴリズムです。保存時の暗号化がない場合、ストレージの侵害はデータの侵害になります。暗号化がある場合、ストレージにアクセスした攻撃者は読めない暗号文を取得します。
どちらも重要です。転送中に暗号化されているが保存時に暗号化されていないプラットフォームは、重要なギャップを残します。
探すべきもの: 転送中のTLS 1.2または1.3、保存時のAES-256。どちらも明示的に記載されるべきで、暗示されるべきではありません。
アクセス制御と最小特権の原則
チームの全員がすべてのフォーム提出物を見ることができるべきではありません。すべてのシステムプロセスがすべてのデータベースに書き込めるべきではありません。最小特権の原則は、各人およびプロセスに必要なアクセスだけを与え、それ以上は与えないことを意味します。
実際には、次のことを意味します：
- 役割ベースの権限 — アナリストは回答を表示できますが、フォームロジックを編集することはできません。管理者は両方を行うことができます
- 多要素認証 — 資格情報の盗難だけではアカウントを侵害するのに十分ではないはずです
- 監査ログ — 誰が何をいつアクセスしたかの記録
監査ログは特に規制産業にとって重要です。医療データを扱っている場合、患者の記録にどの従業員がアクセスしたかを尋ねられたときに、「わからない」という答えは許容されません。
探すべきもの: 設定可能な役割、MFAの強制、改ざん防止のアクセスログ。
インフラストラクチャとネットワークの分離
信頼できるフォームプラットフォームは、クラウドインフラストラクチャ上で実行されており、プロダクション環境が開発環境から分離されています。これは、テスト中に導入されたバグがプロダクションデータに到達しないこと、開発システムの侵害がプロダクションに波及しないことが重要です。
ネットワークレベルの制御—ファイアウォール、仮想プライベートクラウド（VPC）、Webアプリケーションファイアウォール（WAF）—は追加の境界を作成します。アプリケーションサーバーはプライベートサブネットに配置され、インターネットに直接公開されるべきではありません。
探すべきもの: プロダクション/開発の分離、VPCベースのネットワーク分離、公開エンドポイントの前にWAF。
バックアップと冗長性
データの損失もセキュリティの問題です。プラットフォームは冗長なバックアップを維持し、意味のある期間（15日以上が合理的な基準です）保持し、主要データとは別の場所に保存する必要があります。高可用性要件のために、マルチアベイラビリティゾーンアーキテクチャは、1つのデータセンターの障害がサービス全体を停止させないことを保証します。
探すべきもの: バックアップ保持期間、地理的分離、文書化された復旧時間目標。
コンプライアンス認証：実際に何を意味するのか
認証は単なるロゴではありません。それらは、利害関係のない第三者による実際のセキュリティ制御の独立した監査を表しています。
SOC 2 Type II
SOC 2は、サービスプロバイダーが顧客データをどのように扱うかを評価するための米国公認会計士協会のフレームワークです。Type IIはType Iよりも厳格です。制御があるかどうかを一時点で評価するだけでなく、その制御が持続的な期間（通常6〜12か月）にわたって効果的に運用されたかどうかをテストします。
プラットフォームがSOC 2 Type IIを持っている場合、独立した監査人がそのアクセス制御、暗号化慣行、インシデント対応手順、可用性の約束をレビューし、それらが主張通りに機能していると結論付けました。報告書のコピーは、リクエストに応じて、またはベンダーの信頼センターを通じて入手可能です。
ISO 27001
ISO 27001は、情報セキュリティ管理システムの国際標準です。組織がどのようにセキュリティ姿勢を確立、実施、維持、継続的に改善するかをカバーしています—単なるスナップショットではなく、継続的なプログラムです。
ISO 27001:2022が現在のバージョンです。この基準に認定された組織は、セキュリティ管理システムが独立して監査され、基準に適合していると判断されました。
ISO 27017とISO 27018
これらはISO 27001のクラウド固有の拡張です。ISO 27017はクラウドサービスのセキュリティ制御を扱っており、クラウドプロバイダーとその顧客の両方に適用されます。ISO 27018は、クラウド環境での個人識別情報（PII）の保護に焦点を当てています。
クラウドベースのプラットフォームに個人データを保存する企業にとって、これらの認証は基本的なISO 27001標準を超えた意味のある保証を提供します。
HIPAA
HIPAAは、医療機関とそのビジネスアソシエイト—彼らの代わりに保護された健康情報（PHI）を扱う第三者—に適用されます。フォームプラットフォームがHIPAAに準拠するためには、PHIに対する特定の管理的、技術的、物理的な保護措置を実施する必要があります。
重要なのは：HIPAA準拠には、あなたの組織とプラットフォームの間で署名された**ビジネスアソシエイト契約（BAA）**が必要です。BAAがない場合、PHIを収集するためにプラットフォームを使用することは、プラットフォームがどのようなセキュリティ制御を持っているかに関わらず、あなたの組織をHIPAA違反のリスクにさらします。BAAは、両者にとって正式で法的に拘束力のあるコミットメントを作成します。
HIPAA準拠が必要な人とそのペナルティの詳細な内訳については、HIPAAコンプライアンスガイドをご覧ください。
GDPR
GDPRは、組織がEU居住者からの個人データを収集、処理、保存する方法を規制しています。フォームプラットフォームにとって、これは処理のための合法的な根拠を文書化し、データ主体の権利（アクセス、削除、移植性）を提供し、収集したデータに対して適切なセキュリティを維持することを意味します。
フォームプラットフォームに尋ねるべき質問
機密フォームデータをプラットフォームに信頼する前に、これを出発点としてチェックリストとして使用してください。「正しい答え」列は、信頼できる回答がどのように見えるかを示しています。
| 質問 | 正しい答え |
|---|---|
| 転送中および保存時にどの暗号化を使用していますか？ | TLS 1.2/1.3 + AES-256。両方とも明示的に記載されています。 |
| SOC 2 Type II監査を完了しましたか？ | はい、報告書はリクエストに応じて、または信頼センターを通じて入手可能です。 |
| 私のデータはどこに保存されていますか？他の顧客から分離されていますか？ | 指定された地域（例：AWS us-east-1）、テナントレベルの論理的分離。 |
| HIPAA準拠のためにBAAに署名しますか？ | はい—PHIを扱う場合に必要です。 |
| データ保持ポリシーは何ですか？オンデマンドで提出物を削除できますか？ | 設定可能な保持期間、即時削除が可能です。 |
| セキュリティインシデントをどのように処理しますか？ | 通知のための定義されたSLA（GDPRは72時間を要求）、指定された連絡先。 |
| 従業員は私の提出データにアクセスできますか？ | アクセスは制限され、記録され、監査されます。 |
ベンダーがこれらを明確に答えられない場合、それが答えです。
PlatoFormsに関する注意: 上記の表は、信頼できる回答がどのように見えるかを反映しており、必ずしもPlatoFormsの現在の認証ステータスを示しているわけではありません。SOC 2 Type II認証は進行中です。現在の認証ステータスと利用可能なコンプライアンス文書については、信頼センターをご覧ください。
PlatoFormsのセキュリティ対策
PlatoFormsは、医療提供者、法律事務所、金融サービス、規制産業のビジネスなど、機密データを扱う組織のために構築されています。
インフラストラクチャ
- AWSでホストされ、データは転送中にTLS 1.2/1.3、保存時にAES-256で暗号化され、バックアップも含まれます
- プロダクションと開発環境は完全に分離されています
- 顧客データへのすべての従業員アクセスは記録され、監査され、最小特権ポリシーによって管理されています
コンプライアンス
- HIPAA規制の組織のためにビジネスアソシエイト契約に署名します — 設定の詳細については、HIPAAコンプライアンス文書をご覧ください
- HIPAAセキュリティルールの管理的、技術的、物理的な保護措置要件を満たすように設計されています
アカウントセキュリティ
全体像—認証、ダウンロード可能なコンプライアンス文書、セキュリティアーキテクチャの概要については、PlatoForms信頼センターをご覧ください。
医療分野でHIPAA準拠のフォームが必要で、署名されたBAAが必要な場合は、HIPAA準拠のオンラインフォームのためのPlatoFormsをご覧ください。
あなたのユースケースに関するセキュリティについて具体的な質問がある場合は、お問い合わせください。セキュリティ要件は業界や収集されるデータの機密性によって異なり、PlatoFormsが適切かどうかを話し合うことを喜んでお受けします。
