6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

セキュリティチェックと外部認証制度【マルチテナントSaaSにおけるエンジニアリング大全 Day21】

Last updated at Posted at 2025-12-20

Day21.jpg

はじめに

本記事は any Advent Calendar #2 「マルチテナントSaaSにおけるエンジニアリング大全」 Day21 の記事です。 弊社anyのアドベントカレンダーをひとつ丸ごと占有して、ひとりアドベントカレンダーとして、筆者の「マルチテナントSaaSのエンジニアリング」への経験をすべてアウトプットしていくカレンダーです。

今回は、マルチテナントSaaSを運営するうえで避けて通れないセキュリティチェックと外部認証制度について取り扱います。

セキュリティチェックシートについて

B2B SaaSの営業プロセスにおいて、特にエンタープライズ顧客との契約時には「セキュリティチェックシート」の提出を求められることが一般的です。これは顧客の情報システム部門やセキュリティ部門が、ソフトウェアベンダーのセキュリティ体制を評価するために用いる質問票です。Qastでもトライアルの開始前にセキュリティチェックシートをレビューすることがあります。

セキュリティチェックシートでよく見られる質問の例を紹介します🏄‍♂️

データ管理に関する質問

  • 「顧客データはどの国・地域で保管されていますか?」
  • 「データベースの暗号化は実施していますか?(保存時・通信時)」
  • 「テナント間のデータ分離はどのように実現されていますか?」

アクセス制御に関する質問

  • 「多要素認証(MFA)は利用可能ですか?」
  • 「SAML/OIDCによるSSO連携は対応していますか?」
  • 「管理者権限の付与・剥奪のプロセスはどうなっていますか?」

監査とログに関する質問

  • 「監査ログの保存期間はどのくらいですか?」
  • 「顧客が自社の操作履歴をエクスポートすることは可能ですか?」
  • 「システム管理者による顧客データへのアクセスは記録されていますか?」

セキュリティ体制に関する質問

  • 「脆弱性診断は定期的に実施していますか?」
  • 「セキュリティインシデントが発生した場合の通知体制はどうなっていますか?」
  • 「従業員に対するセキュリティ教育は実施していますか?」

セキュリティチェックシートへの対応戦略

セキュリティチェックシートは顧客ごとに異なるため、毎回ゼロから回答するのは非効率です。各社SaaSごとに工夫がありますが、標準的なセキュリティチェックシートを公開している場合もあります。

しかしながら、エンタープライズ企業においては、個社ごとに作成されるExcelなどに個別に回答することになる場合も多く、個社ごとに対応するケースが残ることが現実的でしょう。anyにおいては、セキュリティチェックシートの運用をQast上で蓄積することで、可能な限り回答などのマスター管理を実施しています。

aa4c59ea-cc1e-406f-99ec-0f5b35e529c5.png

認証制度について

B2B SaaSにおいては、エンタープライズ顧客からセキュリティ認証や第三者評価を求められることが一般的です。特に大規模な契約においては、これらの認証取得が事実上の必須要件となっている場合もあります。ここでは、マルチテナントSaaSにおいて重要な認証制度について、国際標準と日本国内の制度の両面から解説します。

ISO/IEC 27001とISO/IEC 27017

ISO/IEC 27001は情報セキュリティマネジメントシステム(ISMS)に関する国際規格であり、組織の情報セキュリティ管理体制を第三者が認証する仕組みです。Qastも取得しており、ISMSに則った情報システム監視体制が用意されています。

CleanShot 2025-12-17 at 16.04.29@2x.pnghttps://qast.jp/security/

さらに、ISO/IEC 27001をベースに、クラウドサービスにおける情報セキュリティ管理について、ISMSクラウドセキュリティ認証(ISO/IEC 27017)という「アドオン認証」も存在します。

特に国内SaaSにおいては、まず第一歩として獲得を目指すとよい認証制度といえるでしょう。

SOC 2(Service Organization Control 2)

国際的にはAICPA SOC 2のほうが著名な認証制度になります。

SOC 2は、米国公認会計士協会(AICPA)が策定したクラウドサービス事業者向けのセキュリティフレームワークです。米国や日本をはじめ、世界各国で広く採用されています。SOC 2では、以下の5つの信頼基準(Trust Service Criteria)が定義されており、「セキュリティ」 「可用性」 「処理の完全性」 「機密性」 「プライバシー」から構成されています。

  • Type I: ある時点での統制の設計と実装を評価
  • Type II: 一定期間(通常6ヶ月以上)にわたる統制の設計と運用の有効性を評価

顧客が契約締結前にSOC 2レポートの提出を要求することがあり、実際にグローバルSaaSにおいては、レポートを開示している企業も多いです。

その他にもGDPR(EU一般データ保護規則)など、必要に応じて対応が求められるでしょう。

さいごに

これらを踏まえると、セキュリティチェックシートや認証制度は、プロダクトのセキュリティ基準を示す重要な指標になります。特にマルチテナントSaaSにおいては、Day3〜Day4で紹介したデータ分離戦略、Day5〜Day6で解説した認証・認可の仕組み、Day16で取り扱ったログ設計など、これまでの設計の積み重ねがセキュリティチェックや認証取得の際に問われることになります。

6
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?