SaaSセキュリティチェックリスト：必須の15のセキュリティ対策

SaaS企業は、顧客情報を保存し、共有インフラストラクチャを通じてリクエストを処理し、APIを介して複数のサービスを接続する場合があります。認証、テナント分離、データ処理のいずれかに脆弱性があると、問題が発生したアカウントやシステムの範囲を超えて情報が漏えいする可能性があります。そのため、SaaS製品を保護するには、ログインページやホスティング環境を安全にするだけでは不十分です。 

この SaaSセキュリティチェックリスト では、アプリケーションアーキテクチャ、インフラストラクチャ、アイデンティティ、データ保護、運用にわたる15の重要なセキュリティ対策を取り上げ、チームが脆弱性を特定し、より信頼性の高いセキュリティプログラムを構築できるよう支援します。

主なポイント

• SaaSのセキュリティには、アプリケーション、インフラストラクチャ、アイデンティティ、データ、運用にわたるセキュリティ対策が必要です。
• マルチテナント型アプリケーションでは、顧客ごとの環境を明確に分離できる境界を設け、それを確実に適用する必要があります。
• 強固な認証、認可、最小権限アクセスにより、不正アクセスのリスクを低減できます。
• セキュアな開発、脆弱性管理、継続的な監視は、脆弱性の特定に役立ちます。
• バックアップ、インシデント対応、復旧計画は、運用上のレジリエンスを支えます。
• セキュリティ対策は、SaaS製品、顧客基盤、脅威環境の変化に応じて継続的に進化させる必要があります。

SaaSセキュリティが重要な理由

SaaSアプリケーションは、相互接続された環境を通じて顧客データや業務プロセスを扱います。ユーザーはさまざまなデバイスや場所からアクセスし、従業員は管理機能を操作し、外部サービスとの連携によって情報がやり取りされます。また、アプリケーションはクラウドインフラストラクチャ、データベース、ストレージサービス、サードパーティ製ソフトウェアに依存する場合もあります。

それぞれの接続には、セキュリティ上の責任が伴います。管理者アカウントが侵害されると、機密性の高い顧客情報が漏えいする可能性があります。認可の不備によって、ある顧客が別の顧客の記録にアクセスできてしまう場合もあります。ストレージサービスの設定ミスによってデータが一般公開される可能性がある一方、安全性の低いAPIによって、メインアプリケーションのインターフェースからは利用できない業務機能が外部に公開されることもあります。

SaaSにおける一般的なセキュリティ課題

SaaSのセキュリティを特に重要なものにしている特徴は、主に3つあります。

1. マルチテナンシー： 複数の顧客が同じアプリケーションインフラストラクチャ、データベース、その他のリソースを利用する場合があります。ある顧客のユーザーが別の顧客の情報にアクセスできないよう、アーキテクチャによって境界を確実に適用する必要があります。
2. 継続的なアクセス： 顧客、従業員、管理者、自動化されたワークロード、連携サービスなどが、さまざまな環境からプラットフォームとやり取りします。アクセスは適切に認証・認可し、監視する必要があります。
3. 連携サービス： SaaSアプリケーションは、クラウドプロバイダー、アイデンティティサービス、外部API、監視ツール、開発プラットフォーム、ソフトウェア依存関係などに依存しています。接続されたコンポーネントの1つに存在する脆弱性が、より広範な環境に影響を及ぼす可能性があります。

The OWASP Multi-Tenant Security Cheat Sheet SaaSアプリケーションは、クラウドプロバイダー、アイデンティティサービス、外部API、監視ツール、開発プラットフォーム、ソフトウェア依存関係などに依存しています。接続されたコンポーネントの1つに存在する脆弱性が、より広範な環境に影響を及ぼす可能性があります。

SaaSセキュリティチェックリスト：必須の15のセキュリティ対策

以下の15項目のセキュリティ対策は、SaaSアプリケーションのセキュリティをレビューする際の実践的な出発点となります。それぞれに、開発チームやセキュリティチームが現在の運用状況を評価するために活用できる実装上のポイントを記載しています。

1. 強固な認証を適用する

セキュリティ目標： 不正なユーザーによるSaaSアカウントへのアクセスを防止する。

認証とは、ユーザーまたはサービスが、そのユーザーまたはサービス自身であることを確認する仕組みです。認証が弱いと、顧客アカウント、管理機能、機密性の高いビジネス情報が危険にさらされる可能性があります。

以下のチェックリストを使用して、認証対策を確認してください。

• 適切なパスワード要件を設定し、利用可能な場合は、一般的に使用されているパスワードや漏えいしたパスワードを拒否する。
• 多要素認証（MFA）をサポートする。
• 特権アカウントや管理者アカウントには、より強固な認証保護を要求する。
• パスワード保存用に設計された、確立されたパスワードハッシュ方式を使用してパスワードを保存する。
• パスワードリセットやアカウント復旧のワークフローを、不正な変更から保護する。
• ブルートフォース攻撃やクレデンシャルスタッフィング攻撃に対して適切な保護を適用する。

MFAは、本番システム、顧客記録、セキュリティ設定にアクセスできるアカウントに対して特に重要です。パスワードが再利用されていたり、漏えいしたり、盗まれたりしている場合、パスワードだけでは十分な保護にならない可能性があります。

ただし、認証はアクセスセキュリティの一部にすぎません。ログインに成功したからといって、ユーザーがすべてのリソースにアクセスできるとは限りません。その判断は認可（Authorization）によって行われます。

確認方法： ログイン、アカウント復旧、多要素認証（MFA）の各フローを確認します。必要な認証保護が適用されていない状態で、特権アカウントが機密性の高い機能にアクセスできないかをテストします。

2. ロールベースアクセス制御と最小権限を実装する

セキュリティ目標： ユーザーやサービスが、必要なリソースにのみアクセスできるようにする。

IDが認証されると、アプリケーションはそのIDで何ができるのかを判断する必要があります。これが認可（Authorization）です。

ロールベースアクセス制御（RBAC）は、あらかじめ定義されたロールを通じて権限を割り当てます。たとえば、SaaSアプリケーションでは、管理者、マネージャー、一般ユーザーなどに個別のロールを設定できます。属性ベースアクセス制御（ABAC）は、部署、リソースの所有者、場所、その他のコンテキスト条件など、追加の属性を評価します。

どちらの方式も、アプリケーションの複雑さに応じてアクセス管理をサポートできます。

アクセス制御のチェックリストには、以下を含める必要があります。

• 実際の業務上の責任に基づいてロールと権限を定義する。
• ユーザー、管理者、サービスアカウントに最小権限アクセスを適用する。
• 機密性の高い管理操作を制限する。
• 権限を定期的に確認し、不要なアクセス権を削除する。
• 従業員の役割が変更された場合や退職した場合は、アクセス権を更新する。
• アプリケーションレベルとAPIレベルの両方で認可ルールをテストする。

重要な誤りの1つは、インターフェース上での表示・非表示を認可そのものとして扱うことです。管理者用ボタンを非表示にしても、不正なユーザーが対応するAPIを直接呼び出すことを防ぐことはできません。

確認方法： 異なるロールのアカウントを使用して、制限された操作を試行します。ユーザーが通常のインターフェースを回避した場合でも、サーバー側で認可されていないリクエストが拒否されることを確認します。

3. セキュアなマルチテナントアーキテクチャとテナント分離を実現する

セキュリティ目標： ある顧客またはテナントが、別のテナントの情報へアクセスすることを防止する。

マルチテナントセキュリティは、共有インフラストラクチャを通じて複数の組織にサービスを提供するSaaSアプリケーションにおいて、最も重要な考慮事項の1つです。

Company AとCompany Bが利用するプラットフォームを想像してみましょう。Company Aのユーザーは、両社が同じアプリケーションやデータベースを利用している場合でも、Company Aに属するレコードのみへアクセスできるべきです。攻撃者がオブジェクトIDやリクエストパラメータを変更し、Company Bの顧客記録を取得できてしまう場合、アプリケーションはテナント分離を適切に適用できていないことになります。

以下のチェックリストを使用してください。

• サーバー側で検証されたIDとメンバーシップを使用してテナントコンテキストを確立する。
• データベースクエリやリソースアクセス時に、テナントの所有権チェックを適用する。
• キャッシュ、ファイルストレージ、バックグラウンドジョブ、その他の共有コンポーネントにもテナント分離を適用する。
• テナント間アクセスや権限昇格についてテストする。
• クライアントから送信されたテナントIDを、認可の証明として決して扱わない。
• 不審なテナント間アクセスの試行を監視する。

テナントの分離を実現するために、必ずしも顧客ごとに個別のデータベースを用意する必要はありません。アクセス境界が一貫して適用されていれば、共有データベースのアーキテクチャでも安全な設計が可能です。適切な分離モデルは、アプリケーションのアーキテクチャ、顧客の要件、リスクプロファイルによって異なります。

確認方法： 異なるテナントのテストアカウントを使用して、お互いのレコード、ファイル、APIリソースへのアクセスを試行します。通常のアプリケーションリクエストだけでなく、バックグラウンドジョブやキャッシュされたデータもレビュー対象に含めます。

OWASP’s Multi-Tenant Security Cheat Sheet では、データアクセスやアプリケーションコンポーネント全体でテナント間の境界を適切に適用するための追加ガイダンスが提供されています。

4. 転送中および保存中の機密データを暗号化する

セキュリティ目標： 機密情報が不正に開示されるリスクを低減する。

SaaSアプリケーションは、異なるサービス間で顧客データを送信・保存します。暗号化は、情報がシステム間を移動する際だけでなく、保存されている間も保護するのに役立ちます。

チェックリストには、以下の項目を含める必要があります。

• 転送中のデータにはHTTPSを使用し、TLSを適切に設定する。
• 保存されている機密データを、適切な暗号化方式を使用して暗号化する。
• データベースのバックアップ、エクスポートされたファイル、その他の顧客情報のコピーを保護する。
• 暗号化キーへのアクセスを制限する。
• キーのローテーションとライフサイクル管理の手順を確立する。
• 機密データがどこに保存され、処理され、送信されているかを特定する。

暗号化はアクセス制御の代替手段ではありません。アプリケーションがデータベースを暗号化していても、過剰な権限、安全性の低いAPI、アプリケーションの脆弱性などによって顧客情報が公開される可能性があります。

確認方法： 通信のセキュリティ、データベースやストレージの設定、バックアップの保護、暗号化キーへのアクセス権限を確認します。実際に機密情報を含むデータフローと保存場所が、暗号化対策によって適切に保護されていることを確認します。

5. 安全なAPIと外部連携を実現する

セキュリティ目標： ユーザー、アプリケーション、サービスが通信するインターフェースを保護する。

APIによって、SaaSアプリケーションはWebアプリケーション、モバイルクライアント、内部サービス、サードパーティプラットフォームなどと接続できます。しかし、安全性の低いAPIが存在すると、メインアプリケーションのインターフェースが安全に見える場合でも、機密性の高い操作が公開される可能性があります。

以下の対策を適用してください。

• APIクライアントを認証し、機密性の高いすべての操作について認可を確認する。
• 受信データを検証し、予期しない入力や無効な入力を拒否する。
• レート制限とリソース消費に対する制御を適用する。
• 実用上可能な場合は、有効期間が短い、または適切な範囲に限定された認証情報を使用する。
• APIキーやアクセストークンが漏えいしないよう保護する。
• サードパーティとの連携と、その権限を確認する。
• 異常なAPIアクティビティや、認証失敗の繰り返しを監視する。

一般的なAPIセキュリティ上の懸念には、オブジェクトレベル認可の不備、過剰なデータ公開、無制限のリソース消費などがあります。たとえば、APIがユーザーのログイン状態を確認していても、そのユーザーが特定の顧客の請求書へアクセスする権限を持っているかどうかを確認していない場合があります。

確認方法： 異なるユーザーロールやテナントIDを使用してAPIエンドポイントをテストします。機密性の高い操作で所有権チェックが適用されているか、またAPIレスポンスに必要な情報のみが含まれているかを確認します。

6. シークレット、認証情報、環境変数を保護する

セキュリティ目標： アプリケーションやインフラストラクチャへのアクセスを可能にする認証情報を攻撃者が取得することを防止する。

シークレットには、APIキー、データベースのパスワード、認証トークン、秘密鍵、その他アプリケーションやサービスが使用する認証情報などが含まれます。これらの値の1つが漏えいすると、通常のユーザー認証を回避するアクセス経路が作られる可能性があります。

以下のチェックリストを使用してください。

• 専用のシークレット管理システムにシークレットを保存する。
• APIキー、パスワード、トークンをソースコードにハードコードしない。
• ワークロードとユーザーの権限に応じて、シークレットへのアクセスを制限する。
• リスク、漏えい状況、運用上の要件に基づいて認証情報をローテーションする。
• 漏えいした認証情報、期限切れの認証情報、使用されていない認証情報を削除する。
• リポジトリやデプロイメント成果物をスキャンし、誤ってコミットされたシークレットを検出する。

シークレットは、アプリケーションの設定ファイル以外にも存在する可能性があります。ソースコードリポジトリ、CI/CDシステム、コンテナ設定、ログ、サードパーティとの連携などにも保存されている場合があります。

確認方法： リポジトリのスキャン結果、デプロイメント設定、シークレットへのアクセスに関するポリシーを確認します。認証情報が漏えいした場合は、失効またはローテーションを行い、実際に使用されたかどうかを調査します。

7. クラウドインフラストラクチャとネットワークアクセスを強化する

セキュリティ目標： クラウドサービスの設定ミスや不要なネットワークアクセスによる露出リスクを低減する。

SaaSアプリケーションのセキュリティは、それを支えるインフラストラクチャに依存しています。一般公開されたストレージ、制限されていないデータベースアクセス、古いサービス、適切に設定されていないネットワークルールなどは、アプリケーション側で適切なセキュリティ対策を行っていても、それを無効にする可能性があります。

インフラストラクチャのチェックリストには、以下を含める必要があります。

• クラウドストレージの権限と一般公開の状態を確認する。
• データベースや内部サービスへのアクセスを制限する。
• 必要に応じて機密性の高いワークロードを分離する。
• 仮想マシン、コンテナ、マネージドサービスに安全な設定を適用する。
• 使用していないポート、サービス、インフラストラクチャリソースを削除する。
• 設定変更や不審なインフラストラクチャアクティビティを監視する。

クラウドインフラストラクチャでは、アプリケーションの運用に必要なサービスとエンドポイントのみを公開する必要があります。管理インターフェースや内部データベースは、具体的かつ正当な要件があり、適切な保護策が講じられている場合を除き、一般公開すべきではありません。

確認方法： ネットワークルール、ストレージ権限、サービスの公開状況、インフラストラクチャ設定、管理者アクセスを確認します。アーキテクチャやデプロイメント環境が変更された際には、これらの設定を再評価します。

8. ソフトウェア開発ライフサイクルを安全にする

セキュリティ目標： 脆弱性のあるコードが本番環境に到達する前に、セキュリティ上の問題を特定する。

セキュリティは、計画段階からデプロイメント、保守に至るまで、ソフトウェア開発の全工程に組み込む必要があります。製品のリリース準備が整うまで対応を待つと、脆弱性への対処がより高コストになり、困難になる可能性があります。

以下のチェックリストを使用してください。

• 開発チーム向けのセキュアコーディング基準を策定する。
• 機密性の高い機能やアーキテクチャ変更について脅威モデリングを実施する。
• 保護されたブランチへマージする前にコード変更をレビューする。
• 必要に応じて静的アプリケーションセキュリティテスト（SAST）を使用する。
• 依存関係をスキャンして既知の脆弱性を検出する。
• ソースコードリポジトリと開発環境を保護する。
• CI/CDの権限とデプロイメント認証情報を制限する。

脅威モデリングを行うことで、チームは機能が実装される前に、その機能がどのように悪用される可能性があるかを検討できます。たとえば、新しいファイル共有機能では、ファイルの所有権、テナント境界、アクセス権限について追加のチェックが必要になる場合があります。

The OWASP Application Security Verification Standard (ASVS) は、アプリケーションセキュリティ要件を定義・検証するための体系的なリソースを提供しています。

確認方法： 開発ポリシー、リポジトリの保護設定、CI/CDのアクセス権限、セキュリティテストの結果、およびチームが特定された脆弱性にどのように対応しているかを確認します。

9. 定期的な脆弱性スキャンとセキュリティテストを実施する

セキュリティ目標： 脆弱性が悪用される前に発見し、対処すること。

SaaSアプリケーションは継続的に変更されます。新機能の追加、依存関係の更新、インフラストラクチャの変更、設定の修正などによって、時間の経過とともにセキュリティ上の弱点が生じる可能性があります。

テストチェックリストには、以下の項目を含める必要があります。

• アプリケーションと依存関係をスキャンし、既知の脆弱性を検出する。
• 重要なリリースの前にセキュリティテストを実施する。
• 認証、認可、テナント分離をテストする。
• 外部に公開されているAPIと管理インターフェースを評価する。
• 重大度とビジネスへの影響に基づいて、脆弱性修正の優先順位を決定する。
• 修正後に再テストを実施し、問題が解決されたことを確認する。

テスト方法によって、それぞれ目的が異なります。自動化された脆弱性スキャンは、既知の問題や一般的な弱点の特定に役立ちます。ペネトレーションテスト（侵入テスト）は、攻撃者の視点からアプリケーションを調査し、悪用可能な侵入経路を特定するものです。より広範なアプリケーションセキュリティテストには、ビジネスロジック、アーキテクチャ、アクセス制御の動作に関する手動レビューが含まれる場合があります。

自動スキャンは有用ですが、すべてのビジネスロジックの欠陥やアーキテクチャ上の弱点を確実に検出できるわけではありません。同様に、ペネトレーションテストは、特定の時点における定義されたテスト範囲を評価するものであり、アプリケーションの安全性を保証するものではありません。

確認方法： テストの対象範囲、未解決の脆弱性、修正までの所要期間、修正後に再テストが実施されたことを示す証拠を確認してください。

10. 安全なログ記録、監視、アラート体制を維持する

セキュリティ目標： 不審なアクティビティを検知し、調査に必要な情報を適切に保存すること。

ログ記録と監視は、SaaSアプリケーション内部で何が起きているのかをチームが把握するのに役立ちます。有用なセキュリティログがなければ、インシデントの発生源や影響範囲を特定することが困難になる可能性があります。

チェックリストには、以下の項目を含める必要があります。

• 認証イベントとアクセス失敗の試行を記録する。
• 機密性の高い管理者操作を記録する。
• 異常なAPIリクエストやアカウントアクティビティを監視する。
• テナント固有のセキュリティイベントには、関連するテナント情報を含める。
• 不正なアクセスや改ざんからログを保護する。
• 適切なログの保存期間とレビュー方針を定める。
• 重要なセキュリティイベントに対するアラートを設定する。

マルチテナントアプリケーションでは、調査担当者がどのテナントやリソースに関係する事象なのかを特定できるだけの情報をログに含める必要があります。同時に、ログシステムでは不要な顧客情報を収集しないようにする必要があります。

通常のアプリケーションログには、パスワード、アクセストークン、セッション識別子、その他の機密性の高い認証情報を絶対に記録しないでください。

確認方法： 重要なセキュリティイベントが記録されているか、アラートが担当チームに適切に届いているか、ログが保護されているかを確認します。また、不要な顧客データを漏えいさせることなく、調査担当者が関連するアクティビティを再構築できるかどうかをテストしてください。

11. データバックアップと災害復旧手順を確立する

セキュリティ目標： データ損失、インフラストラクチャの障害、またはセキュリティインシデントが発生した後も、サービスの可用性を維持し、重要な情報を復旧できるようにすること。

バックアップは、誤操作によるデータ削除、インフラストラクチャの障害、特定のセキュリティインシデントからSaaS企業を保護するのに役立ちます。しかし、バックアップを作成するだけでは十分ではありません。許容可能な時間内にアプリケーションとそのデータを復元できるかどうかを、チームが把握しておく必要があります。

以下のチェックリストを使用してください。

• ビジネス要件とデータ要件に応じて、バックアップの頻度を定義する。
• バックアップを暗号化し、アクセスを制限する。
• 保護されたバックアップコピーを維持する。
• 復元手順を定期的にテストする。
• 目標復旧時間（RTO）と目標復旧時点（RPO）を定義する。
• 該当する場合は、テナントごとの復旧手順を検証する。

RTOは、サービスに障害が発生してから、どれくらいの時間でサービスを復旧すべきかを示します。一方、RPOは、ビジネスが許容できるデータ損失の最大量を時間で表したものです。

マルチテナントプラットフォームでは、他の顧客に影響を与えることなく、必要に応じて個別のテナントのデータを復元できるかどうかも、復旧計画に含める必要があります。

確認方法： 復元訓練を実施し、その結果を文書化します。復元したデータが実際に使用可能であること、および復旧手順が組織で定められた要件を満たしていることを確認します。

12. 従業員、管理者、サービスアカウントを保護する

セキュリティ目標： 内部アクセスおよび人間以外のID（Non-Human Identities）に関連するリスクを軽減すること。

すべてのセキュリティリスクが外部顧客のアカウントから発生するわけではありません。従業員、契約社員、管理者、自動化されたワークロード、外部連携なども、機密性の高いシステムにアクセスする可能性があります。

チェックリストには、以下の項目を含める必要があります。

• 特権ユーザーに多要素認証（MFA）を必須とする。
• 本番環境へのアクセスを許可された従業員に限定する。
• 従業員および管理者のアクセス権限を定期的に見直す。
• 従業員の退職時には、速やかにアクセス権限を削除する。
• 自動化されたワークロードには専用のサービスIDを使用する。
• 特権アカウントのアクティビティを監視する。
• 管理者の認証情報を共有しない。

サービスアカウントには、特に注意を払う必要があります。自動化されたプロセスがデータベースやAPIへのアクセスを必要とする場合でも、環境全体に対する無制限の権限を付与する必要はありません。

確認方法： アカウント一覧、特権アクセス権限、サービスアカウントのアクセス許可、および退職・契約終了時のアカウント停止記録を確認します。非アクティブなアカウント、複数人で共有されているアカウント、または正当な業務上の必要性がなくなったアカウントについて調査します。

13. サードパーティおよびサプライチェーンのセキュリティを管理する

セキュリティ目標： 外部ソフトウェア、ベンダー、サービスプロバイダーによって生じるリスクを軽減すること。

SaaSアプリケーションは、外部サービスやソフトウェアの依存関係に大きく依存しています。これには、クラウドプロバイダー、決済処理サービス、認証サービス、分析プラットフォーム、オープンソースライブラリ、開発ツールなどが含まれます。

連携しているサービスに脆弱性があると、アプリケーション全体のセキュリティに影響を及ぼす可能性があります。

以下のチェックリストを使用してください。

• 重要なサードパーティサービスとソフトウェア依存関係の一覧を管理する。
• ベンダーがアクセスするデータや権限に基づいて、そのセキュリティを評価する。
• 外部連携のアクセス権限を見直し、不要なアクセスを取り消す。
• ソフトウェア依存関係の脆弱性を監視する。
• ベンダーに関連するセキュリティインシデントを確認するためのプロセスを確立する。
• 重要なセキュリティ上および契約上の責任を文書化する。

ベンダーの評価では、サービスプロバイダーがどのような情報にアクセスできるのか、その情報がどのように保護されているのか、さらにサービスでインシデントが発生した場合にどのような対応が行われるのかを確認する必要があります。

確認方法： ベンダー一覧、連携システムのアクセス権限、依存関係のスキャン結果、および関連する契約書やセキュリティ文書を確認します。

14. インシデント対応計画を策定する

セキュリティ目標： セキュリティインシデントが発生した際に、チームが一貫した対応を実施できるようにすること。

予防的なセキュリティ対策を導入していても、SaaS企業にはインシデントへの対応計画が必要です。アカウントの侵害、データの漏えい、ランサムウェア、サービスの停止、サードパーティによる侵害など、それぞれの状況に応じて異なる技術的対応やコミュニケーションが求められる場合があります。

インシデント対応チェックリストには、以下の項目を含める必要があります。

• インシデントの重大度レベルとエスカレーション手順を定義する。
• インシデント対応における役割と責任を割り当てる。
• 影響を受けたシステムやアカウントを隔離する手順を確立する。
• 顧客や関係者への連絡・情報共有プロセスを準備する。
• 調査に必要な証拠を保全する。
• インシデント対応訓練を実施する。
• 得られた教訓と是正措置を文書化する。

効果的な計画では、誰が意思決定を行い、誰が技術的な問題を調査し、誰が影響を受けた顧客や関係者に連絡するのかを明確にする必要があります。また、該当する場合には、契約上および法的な通知義務も考慮する必要があります。

The NISTサイバーセキュリティフレームワーク2.0 は、「ガバナンス（Govern）」「特定（Identify）」「防御（Protect）」「検知（Detect）」「対応（Respond）」「復旧（Recover）」という6つの機能を通じて、サイバーセキュリティ活動を体系化するための有用な枠組みを提供しています。

確認方法： 机上演習（テーブルトップ演習）やその他のインシデント対応シミュレーションを実施します。チームメンバーがそれぞれの役割と責任を理解し、文書化された手順に従って適切に対応できるかを確認します。

15. セキュリティガバナンス、プライバシー、コンプライアンスの実践を確立する

セキュリティ目標： セキュリティに関する責任を測定可能かつ文書化し、ビジネスおよび顧客の要件に適合させること。

技術的なセキュリティ対策には、組織的なサポートが必要です。SaaS企業は、ポリシーを策定し、責任を明確に割り当て、重要なセキュリティ活動が適切に実施されていることを示す証拠を維持する必要があります。

以下のチェックリストを使用してください。

• セキュリティポリシーと責任範囲を文書化する。
• 適用される法律、規制、契約上の要件を特定する。
• データの保持および削除に関するポリシーを策定する。
• 顧客からのデータに関するリクエストに対応するプロセスを確立する。
• セキュリティ対策を定期的に見直す。
• 例外事項と改善計画を文書化する。
• 重要なセキュリティ活動の実施記録を維持する。

SaaS企業には、以下のようなフレームワークや規制が関連する場合があります。

これらのフレームワークや規制は、相互に置き換えられるものではありません。その適用可否は、SaaS企業の事業活動、顧客との契約上の義務、取り扱うデータの種類、事業を展開する法域によって異なります。

このチェックリストを完了しただけで、企業が自動的にSOC 2に準拠したり、ISO 27001認証を取得したり、特定の規制への準拠を達成したりするわけではありません。各組織は、自社に適用される要件を評価し、適切な証拠を継続的に維持する必要があります。

SaaSセキュリティ改善の優先順位を決める方法

SaaSチームには、すべてのセキュリティ改善を一度に実施できるだけのリソースがない場合があります。実践的なアプローチは、リスク、脅威への露出度、ビジネスへの影響、既存のセキュリティ上の弱点に基づいて優先順位を決めることです。

基本的なセキュリティ対策から始める

まず、以下の基本的な保護対策を見直しましょう。

• 特権アクセスに対する認証と多要素認証（MFA）。
• 認可と最小権限の原則に基づくアクセス権限の設定。
• マルチテナント環境の分離。
• 暗号化とシークレット管理。
• 安全なAPIアクセス。
• 脆弱性の特定と修正。
• 検証済みのバックアップとインシデント対応。

これらの対策は、アプリケーションと運用のセキュリティにおける重要な領域をカバーします。ただし、優先順位は、製品のアーキテクチャ、顧客データ、脅威への露出状況を踏まえて決定する必要があります。

継続的なセキュリティ改善プロセスを構築する

繰り返し実施できるセキュリティレビューのプロセスを確立することで、チームは個別の問題への一時的な対処から、継続的なリスク管理へと移行できます。

1. 重要な資産を特定する： 機密データ、重要なサービス、アプリケーションの構成要素、外部依存関係を文書化します。
2. リスクを評価する： 脅威、既存の脆弱性、およびビジネスへの潜在的な影響を調査します。
3. 管理策の責任者を割り当てる： 特定のセキュリティ対策の実装と維持について、個人またはチームに責任を割り当てます。
4. 修正の優先順位を決める： 最も重大なリスクや外部に露出している脆弱性から優先的に対処します。
5. 有効性を検証する： 実装したセキュリティ対策が意図したとおりに機能しているかをテストします。
6. 定期的に見直す： 製品、インフラストラクチャ、または脅威環境に変化があった場合は、セキュリティプログラムを再評価します。

NIST CSF 2.0は、このプロセスを体系化する際に役立ちます。6つの機能である「ガバナンス（Govern）」「識別（Identify）」「防御（Protect）」「検知（Detect）」「対応（Respond）」「復旧（Recover）」は、リスク管理のための枠組みを提供するものであり、必須の認証制度やすべての組織に共通する実施スケジュールを定めるものではありません。

SaaSセキュリティで避けるべきよくある間違い

SaaS企業が複数のセキュリティ対策を導入していても、特定のミスによって、それらの対策の有効性が損なわれる可能性があります。

認証だけでセキュリティが完了したと考えること

安全なログインシステムを導入していても、認可チェックが欠如していたり、正しく実装されていなかったりすると、リソースを保護できません。機密性の高い操作にはすべて、適切なアクセス権限の確認が必要です。

テナントIDだけでデータが分離されていると考えること

テナントIDが存在するだけでは、ユーザーがそのテナントに所属している証明にはなりません。アプリケーションでは、データベースクエリ、API、ファイル、その他のリソース全体にわたって、テナントへの所属とデータの所有権を検証し、適切な分離を徹底する必要があります。

自動化されたセキュリティスキャンだけに依存すること

自動化ツールは既知の脆弱性を多数検出できますが、ビジネスロジックの欠陥、認可の弱点、アーキテクチャレベルの問題を見逃す可能性があります。自動テストと適切な手動によるセキュリティレビューを組み合わせることが重要です。

サードパーティや内部アクセスを軽視すること

外部連携、サービスアカウント、CI/CDシステム、従業員のアクセス権限は、アプリケーションへの新たな侵入経路となる可能性があります。セキュリティプログラムの一環として、これらのアクセスポイントも定期的に見直す必要があります。

セキュリティを一度限りのプロジェクトとして扱うこと

新機能の追加、依存関係の変更、インフラストラクチャの更新、進化する脅威に対応するため、継続的な見直しが必要です。セキュリティは、製品開発と運用の両方において、常に重要な要素として組み込まれている必要があります。

SaaSセキュリティに関するよくある質問

SaaSセキュリティチェックリストとは何ですか？

SaaSセキュリティチェックリストとは、SaaSアプリケーション、インフラストラクチャ、データ、ID管理、運用のセキュリティを評価・改善するために使用される、体系的な管理項目の一覧です。認証、テナント分離、暗号化、監視、インシデント対応などのセキュリティ対策を見直し、チームが脆弱性や不備を特定するのに役立ちます。

SaaS企業にとって最も重大なセキュリティリスクは何ですか？

一般的なリスクには、不正なアカウントアクセス、顧客データの漏えい、テナント間の脆弱性、安全でないAPI、クラウド設定の不備、認証情報の侵害、ソフトウェア依存関係の脆弱性、サービスの停止などがあります。具体的なリスクは、アプリケーションのアーキテクチャ、取り扱うデータ、外部連携の内容によって異なります。

SaaS企業はどのように顧客データを保護できますか？

SaaS企業は、暗号化、適切なアクセス制御、テナント分離、安全なAPI、データ保持ポリシー、監視、検証済みのバックアップを通じて、顧客データを保護できます。さらに、これらの対策を安全な開発プロセスと定期的なセキュリティレビューによって支えることが重要です。

マルチテナントセキュリティとは何ですか？

マルチテナントセキュリティとは、複数の組織が共有のSaaSアプリケーションやインフラストラクチャを利用する際に、各顧客の環境とデータを保護するためのセキュリティ対策です。これにより、ユーザーは自身がアクセスを許可されたテナントに属する情報やリソースのみにアクセスできるようになります。

SaaSのセキュリティ責任はプロバイダーと顧客のどちらにありますか？

SaaSのセキュリティには、プロバイダーと顧客の双方が担う責任があります。プロバイダーは、アプリケーションおよび基盤となるサービスのセキュリティを管理します。一方、顧客にも、アクセス権限の設定、ユーザー管理、認証情報の保護、サービスの安全な利用が求められます。具体的な責任範囲は、利用するサービス、契約内容、セキュリティ上の取り決めによって異なります。

SaaS企業が従うべきセキュリティフレームワークは何ですか？

OWASP ASVSは、アプリケーションのセキュリティ要件を定義し、その適合性を検証する際に役立ちます。一方、NIST CSF 2.0は、組織全体のサイバーセキュリティリスク管理を支援します。SOC 2とISO/IEC 27001は、それぞれ異なる保証要件と情報セキュリティマネジメントのニーズに対応しています。適切なフレームワークは、ビジネス目標、顧客の期待、適用される規制や要件に応じて選択する必要があります。

SaaSのセキュリティはどのくらいの頻度で見直すべきですか？

セキュリティは継続的に監視し、リスク、製品の変更、組織の要件に応じて、正式なレビューやテストを計画的に実施する必要があります。また、大規模なアーキテクチャの更新、新たな外部連携、重要なリリース、セキュリティインシデントが発生した場合には、追加の評価を実施することも求められます。

まとめ

SaaSのセキュリティは、インフラストラクチャの保護や多要素認証（MFA）の導入だけにとどまりません。アプリケーションアーキテクチャ、テナント分離、認証、API、データ保護、開発、監視、インシデント対応など、幅広い領域にわたって連携したセキュリティ対策が必要です。

このチェックリストを活用して、セキュリティ上の不足箇所を特定し、責任者を割り当て、実際の製品リスクに基づいて改善の優先順位を決定しましょう。SaaSアプリケーションの成長に合わせて、新機能、顧客、外部連携、運用要件の変化を考慮し、これらのセキュリティ対策を定期的に見直すことが重要です。AI搭載のSaaSアプリケーションを開発している場合や、既存製品のモダナイゼーションを検討している場合は、ShadhinLabのAIソリューションをご覧いただき、アプリケーション開発に関する要件についてぜひご相談ください。