SaaSプロダクトチームのセキュリティチェックリスト：リリース前とリリースごとに確認すべき10の領域

このチェックリストは、マルチテナントプロダクトを開発・提供し、顧客のセキュリティ質問票に回答する必要があるプロダクトマネージャー、エンジニアリングリード、創業者を対象としています。SaaSプラットフォームエンジニアリングガイドでは、セキュリティの基本事項を簡潔にまとめていますが、本ページではそれをチームがチェックできる項目に落とし込み、添付すべき証拠とともに整理しています。

本ガイドの内容

• チェックリストの使い方
• 10の領域一覧
• テナント分離：SaaSプロダクトが失敗しやすい領域
• 認証・アクセス管理、APIとビジネスロジックの確認
• データ、シークレット、サプライチェーン
• ログ管理、リカバリ、インシデント対応
• AI機能のセキュリティ
• レビューの実施者：選択肢と選択基準
• レビュープラン
• NetbaseのSaaSプロダクト構築とチェック方法
• 存在するデリバリ実績と存在しないもの
• 本ガイドの限界
• よくある質問
• 次のステップ

チェックリストの使い方

各項目は、担当者、現在の証拠、最終確認日の3つの要素を持つ問いとして扱ってください。担当者が決まっていない項目は、コードの状態にかかわらず完了とはみなせません。顧客のセキュリティレビューに記憶ではなく記録で対応できるよう、リポジトリなど一か所に回答をまとめておきましょう。

リストの誠実さを保つ2つのルールがあります。テスト、ログ、設定、またはドキュメントで確認できる場合のみチェックを入れ、アーキテクチャ図ではなく現在運用しているプロダクトに対してリストを実行してください。

10の領域一覧

テナント分離：SaaSプロダクトが失敗しやすい領域

アクセス制御は、Webアプリケーションで最も頻繁に失敗する領域です。OWASP Top 10:2025では、Broken Access Controlが第1位に挙げられています。マルチテナントプロダクトでは、テナントチェックが1か所でも欠けると、あるお客様のデータが別のお客様に見えてしまう可能性があります。OWASP Multi-Tenant Security Cheat Sheetは、これを具体的なコントロールに落とし込んでいます：

• テナントを検証済みのアイデンティティに紐づける。クライアントが送信する値ではなく、サーバーサイドのセッションからテナントを取得し、すべてのリクエストでメンバーシップを確認します。
• すべてのルックアップにスコープを設定する。データベースクエリにテナントを含めるか、行レベルポリシーでデータベース側で強制し、推測されたIDで別テナントのレコードが返らないようにします。
• テナントでキャッシュをキーイングする。キャッシュエントリのキーにテナントが含まれていないと、あるお客様のページが別のお客様に提供される可能性があります。
• テナント情報をキューとジョブを通じて引き継ぐ。バックグラウンドジョブは実行対象のテナントを再確認する必要があり、ストレージパスと署名付きファイルリンクも同じスコープと短い有効期限が必要です。
• クリーンにオフボードする。テナントが離脱したら、認証情報を失効させ、バックアップとファイルストレージに保持ルールを適用します。

マルチテナントSaaSアーキテクチャガイドでは、これらのコントロールの背後にある分離モデルを比較しています。

認証・アクセス管理、APIとビジネスロジックの確認

認証・アクセス管理。管理者には多要素認証を必須とし、すべてのユーザーにも提供します。また、要望のあるビジネスお客様にはシングルサインオンをサポートします。ロールは少なく明確に保ち、セッションを期限切れにし、管理者権限を四半期ごとにレビューします。

APIセキュリティ。SaaSの機能の大部分はAPIであるため、OWASP API Security Top 10（2023）は実践的なテストリストです。オブジェクトレベルの認可（API1）、認証（API2）、プロパティレベルの認可（API3）、リソース消費の無制限（API4）、ファンクションレベルの認可（API5）から始めてください。旧バージョンも含め、すべてのエンドポイントのインベントリを維持してください。不適切なインベントリ管理はAPI9です。

ビジネスロジック。一部の欠陥は1つのリクエストのバグではなく、シーケンスの問題です。支払いステップのスキップ、招待の再利用、プランが許可する以上のエクスポートなどが該当します。API6はこれを機密ビジネスフローへの無制限アクセスと呼んでいます。サインアップ、招待、請求、エクスポートの意図したフローを文書化し、各ステップがインターフェースで非表示にするだけでなく、サーバー側で強制されることをテストします。

データ、シークレット、サプライチェーン

• 転送中および保存中のデータを暗号化し、アプリケーションコードの外にキーを保管して、各キーに担当者を割り当てます。
• データを分類する。個人情報や機密情報を含むフィールドを把握し、ログ・エクスポート・アナリティクスなどコピーされる場所と、各コピーの保持期間を確認します。
• シークレットをリポジトリに入れない。スキャンを実施し、シークレットストアを使用し、環境ごとに独自の認証情報を付与し、担当者が退職した際にローテーションします。
• 依存関係を把握する。パッケージとコンテナイメージをスキャンし、マージ前にコードをレビューし、どのバージョンがどこで動作しているかの記録を保持します。NIST Secure Software Development Framework（SP 800-218）はこの背後にある実践を説明しており、OWASPのApplication Security Verification Standardはチケットで参照できる要件を一覧にしています。
• サードパーティサービスをアタックサーフェスの一部として扱う。各インテグレーションキーは必要最小限の権限にスコープし、OWASPはアップストリームのレスポンスを過度に信頼する場合をAPIの安全でない消費（API10）として指摘しています。

ログ管理、リカバリ、インシデント対応

「誰がいつこのテナントのデータにアクセスしたか」に答えられないプロダクトは、調査も証明もできません。サインイン、権限変更、エクスポート、管理者アクションをテナントとユーザーとともにログに記録し、ログを説明対象の人物から保護し、繰り返される失敗やクロステナントアクセスの試みにアラートを設定します。

バックアップは復元して初めて意味を持ちます。環境全体と、単一テナントをクリーンな環境に復元し、日付と結果を記録して、大きな変更後に繰り返します。インシデント対応については、担当者を明示した簡潔なプラン、顧客通知のタイミングの判断基準、通知テンプレートを用意し、最初の実際のインシデントより前にテーブルトップ演習を実施してください。

レビューの実施者：選択肢と選択基準

4つの基準で選択してください：顧客が契約で要求する内容、データの機密性、リリース頻度、チームにセキュリティを担えるメンバーがいるかどうか。多くのプロダクトでは最初の2つを組み合わせる必要があります：定期的なチェックリストと、主要なローンチ前の外部テストです。

NetbaseのSaaSプロダクト構築とチェック方法

Netbaseは、クライアント向けにマルチテナントプロダクトを構築・運用するとともに、自社プロダクトも運営しています。公開されているセキュリティ実践は、セキュアコードレビューとバージョン管理、転送中のTLSと保存中のAES暗号化、ロールベースアクセス制御、管理者ダッシュボードのMFA、脆弱性スキャンとペネトレーションテスト、ディザスタリカバリです。NDA、データ処理契約、SLAはご要望に応じてご提供します。NetbaseはISO 27001認証とSOC 2 Type II認証を保持しています。いずれもNetbase自体の運営に関するものであり、クライアントのプロダクトやホスティングには適用されず、クライアント側でも独自のコントロール、証拠、そして顧客から求められる場合は独自の監査が必要です。NetbaseはAWS、Google Cloud、DigitalOcean、Cloudflareで稼働しており、クラウドパートナーティアは主張していません。Netbaseのほとんどのプロジェクトは、ディスカバリ後に合意した請負契約で提供されます。SaaS開発、再利用可能なアカウント・テナント・ロールを提供するSaaSプロダクトアクセラレータ、テストのためのアプリケーションセキュリティアシュアランスもご覧ください。MVPロードマップでは最初の数週間にこれらのチェックを位置づけており、ベンダーの回答を評価するにはソフトウェア開発パートナーへのセキュリティ質問をご参照ください。

存在するデリバリ実績と存在しないもの

• 存在するもの。Netbaseは、マルチテナントのデジタルワークプレイスであるCloodo Workspaceと、多くのマーチャントにサービスを提供するSaaSであるPrintcartを構築・運営しています。2020年以降、米国クライアント（社名非公開）のマルチテナントクラウドERPにおいてオフショア開発・マネージングパートナーとして従事しています。
• 存在しないもの。Netbaseの公開記録には、ペネトレーションテスト結果、インシデント履歴、監査所見、脆弱性件数、応答時間は掲載されておらず、特定のコントロールが機能することの証拠として提供されるものもありません。このページはいかなるプロダクトの認証も行いません。

本ガイドの限界

• これはコンプライアンスプログラムではなく作業用チェックリストです。決済や医療などの規制業種には独自の要件が加わるため、専門家のアドバイスを受けてください。
• 標準は変化します：レビューを行う日に、最新のOWASP、NIST、プロバイダーのガイダンスを確認してください。
• チェックリストは未知の欠陥を発見できません。それはテストと独立したレビューの役割です。

よくある質問

SaaSスタートアップが最初に確保すべきことは何ですか？テナント分離とアクセス制御、次にシークレット管理、復元済みのバックアップ、そしてログです。これらは最小の労力で最大の被害を防ぎ、顧客も最初に尋ねる事項です。

SaaSを販売するためにSOC 2やISO 27001は必要ですか？顧客が要求する場合のみです。多くのバイヤーは質問票から始め、後でレポートを求めます。上記のチェックリストはどちらの場合にも回答を提供します。

どのくらいの頻度でレビューすべきですか？主要なリリースごと、および少なくとも四半期ごとに実施し、ビジネスお客様へのローンチ前または主要な変更後に独立したテストを行います。

ペネトレーションテストはチェックリストの代わりになりますか？なりません。テストは外部者によるスナップショットです。チェックリストはテストの間もコントロールを維持します。

次のステップ

テナンシーモデル、現在の証拠、顧客から送られてくる質問票を共有していただければ、ソリューションレビューをご予約して10の領域のギャップをマッピングします。SaaS開発やNetbaseのインサイトもご覧ください。

関連サービスとソリューション