うぐいすソリューションズTechBlogPublicationへの投稿
🔐

【サーバレス】リリース間もないSaaSのセキュリティチェックシートに苦しんだ【AWS】

ぴよ
に公開
AWS
Security
Serverless
SaaS
tech

はじめに

技術顧問としてSaaSのベータ版リリースに関わる中で、セキュリティチェックシートを記入する機会がありました。しかも、営業がやたら優秀なせいでまあまあな企業の出すオリジナリティに溢れるフォーマットのシートを複数です。私自身はセキュリティやインフラが専門領域ではないうえ、ベータ版の段階では実績データも資金もなく、「これどう書くんだ....」となる場面がありました。

この記事では、同じような悩みを抱える方や、将来再びセキュリティチェックシートと向き合う自分のために、特に悩んだ項目について、どんな回答にしたかを記録としてまとめておこうと思います。

前提

この記事で対象とするのは、以下のようなSaaSサービスです。

  • ベータ版をリリースしたばかりで、顧客の利用数はまだ少ない
  • AWS Lambda, RDS, API Gateway, Route53などを中心としたサーバレスアーキテクチャ

ネットワーク

TLSまわり

いくつかのセキュリティチェックシートでは、TLSのバージョンや証明書の種類についての項目がありました。

  • TLSバージョン: AWSのACM（AWS Certificate Manager）を利用している場合、2025年8月末時点ではTLS 1.2が必須、TLS 1.3が推奨です。デフォルトなら「TLS 1.2」が回答になるはず。
    • Chromeの開発者ツール（F12キー）の「Security」タブで、利用しているTLSバージョンを確認できます。
  • 証明書の種類: SSL/TLS証明書には、検証レベルに応じて以下の3種類があるようです。
    • DV (ドメイン認証): ドメインの所有権のみを証明します。最も手軽に取得できます。
    • OV (組織実在認証): ドメインの所有権に加え、運営組織が法的に実在することを証明します。
    • EV (拡張認証): 最も厳格な認証プロセスを経て発行され、組織の法的・物理的な実在性を証明します。
    • ACMで発行できる証明書はDV証明書のみです。インポートすればOVやEV証明書も使えますが、デフォルト設定なら「DV証明書」が回答になります。

ロギング

ロギングはほとんどのセキュリティチェックシートで聞かれていました。ふわっと「どんなログをとっていますか？」という書き方になっていて、「どんなログってどういうことだ....」としばらく紙面（Excel面）を睨みつけてしまいました。

ログの種類

どうやら2種類あるので、回答するときに「どこで」「どんな種類のアクセスログ」を取得しています、といった書き方がミニマムになるようです。追加で、ログの内容と、利用者がログをほしがったときに提供できるか、も聞かれることがありました。

  • アクセスログ: 「誰が／どこから／何に／どうアクセスしたか」というリクエストの記録です。ALB/NLBやAPI Gateway, S3などで設定できます。Amplifyでも自動で保存されます。
  • 実行ログ（アプリケーションログ）: 「アプリケーション内部で何が起きたか」という処理の記録です。
    • DEBUG, INFO, WARN, ERROR , FATAL といったログレベルがよくあります。
      • 本番環境ではINFOレベル以上を出力することが多い印象です。
      • WARNはエラーだけど正常系には影響がないやつ、ERRORは正常にエラーがthrowされたやつ、FATALは手動オペレーションがいるとか、エンジニアの電話がなりそうなやつ、と私は思っています。

信頼性

MTTR（平均復旧時間）

Mean Time To Repairの略で、障害発生から復旧までにかかる時間の平均値とのことです。
可能であれば、過去の障害対応実績から実測値を記載するのが理想ですが、ベータ版で実績がなかったため、SLO（Service Level Objective）で目標を定める....ということになるのですが、正直SLOも勝手に決めていいかわからん、けど私以外に決める人もおらん、といった状況だったので、当時のエンジニア体制でなんとかなりそうな値を設定しました。

RTO（目標復旧時間）

Recovery Time Objectiveの略で、障害発生時にシステムをどれくらいの時間で復旧させるかという目標時間とのことです。
こちらもMTTRと同様、現状の運用で確実に守れそうな時間を記載したのと、「全部元通りだよ！」までやりきる自信がなかったので、約束する前提あわせとして具体的な復旧手順を記載しました。

復旧手順: 監視アラートを起点とし、一次切り分けを実施。その後、RDSのスナップショットからの復元とアプリケーションの再デプロイを行い、システムを復旧させます。

こんな感じにね....。

性能

応答時間・処理の遅延継続時間

これらの項目は、負荷テストなどを実施して実測値を記載するのが基本のようです。ベータ版であれば、想定される負荷に基づいたテストを行います。がそんな余裕はなかったし、必須項目じゃなかったので埋めませんでした。これを聞いてきたシートは1枚だけだったから....

拡張性

同時接続利用者数

同時接続利用者数（何人まで接続できるか、上限を聞いている）はシステムのボトルネックから計算しました。 いくつになったかは覚えていないのですが、 例えばNext.js / Fargate 1vCPU・2GBという構成なら、DBコネクションプール数がボトルネックになることが多く、1タスクあたり20接続が上限となります。

なお、真面目にやつ場合、さらにSLO条件下での平均処理時間、RPS（Request Per Second）をかけて、接続理論値を出し、どちらか小さい方を実際の値として採用するといい、とGPTちゃんが言っていました。さらに安全サイドにふるなら0.8がけして「16人/タスク」みたいにして記載するのが慣習とのこと。

データ管理

コネクションプール

  • RDSとECSの構成の場合: DBインスタンスのスペックやDBエンジン、ORMの設定によって接続数が決まります。
  • RDSとLambdaの構成の場合: RDS Proxyを利用することが一般的です。RDS Proxyでは、接続プールの最大接続数（max_connections）に対して何%まで接続を許可するかを設定できるので、「RDSとECSの構成の場合」と同様、DB側の最大接続数を調べて、それの何%接続できるか計算します。

バックアップ

RDSの自動バックアップ機能はデフォルトで使っていたので、デフォルト値をメモします。

  • バックアップサイクル: 1回/日。これとは別に、5分ごとにデータベース変更ログのアーカイブが自動で行われます（ポイントインタイムリカバリ用）。
  • バックアップ開始時刻: リージョンごとに定められた8時間の時間ブロックからランダムに選択されます（変更可能）。
  • バックアップ保持期間: デフォルトは7日ですが、0日（無効）から最大35日まで変更可能です。

マルチテナントの場合のキー管理

RDSの保存データ暗号化は、クラスタ/インスタンス単位で1つのKMSキーを使用します。そのため、アプリケーション側で何もしなければ、全テナントのデータが単一のキーで暗号化されることになります。
（これでお客さんにセキュアじゃないと言われたら、アプリケーション層でエンベロープ暗号化（KMSで暗号化したデータキーを使い、各テナントのデータを個別に暗号化する方式）を検討します。）

サーバ管理状況

サーバレスの時ってどうだっけ、ってなる項目まとめです。これらの項目もセキュリティシートに頻出でした。

  • 利用OS: 該当なし（LambdaやECSの実行環境はAmazon Linuxですが、利用者が管理する必要はないため該当なしで記載）
  • ウィルス対策: 該当なし（AWSのマネージドサービスのため）
  • パッチ適用: 該当なし（OSレベルのセキュリティパッチはAWSによって随時適用される）
  • 操作記録: CloudTrailでAWS APIの呼び出し履歴を記録・保持

物理的な管理

「入退室管理」とか「盗難防止」とかの状況について聞く項目もありました。フルリモートだしなんて答えれば....と思っていたのですが、どうやら「データセンター」のサーバの話だったみたいです。例えば入退室管理の場合、データセンターはAWSが持っているので、適切な回答は「AWSのデータセンターの運用に準ずる、となります。参考URLとしてAWSのデータセンターのページを添えました。

その他

大手企業向けのサービスの場合は以下を事前に考えておくと、セキュリティチェックで突っ込まれにくいなと思いました。私はセキュリティチェックシートを受け取ってから急いで実装したり導入したりしました。

入れておくべきAWSサービス

  • CloudTrail: AWSアカウント操作ログを取得する。
  • WAF (Web Application Firewall): 一般的なWeb攻撃からアプリケーションを保護する。RateLimitの設定もできたはず。
  • スイッチロール: 環境やサービスごとにAWSアカウントを分離する場合に必須。ステップアカウントを作って、ロールベースでアクセス管理を行う。

決めておくべき運用ルール

  • 稼働時間
  • 問い合わせフロー
  • 計画停止や定期リリースのスケジュール
  • サービス提供終了時の通知方法とデータの扱い
  • SLO（Service Level Objective）

意識しておくべきセキュリティ

  • IAM制限: 各リソースへのアクセス権限を最小限にします。
  • セキュリティグループ最小化: 必要なポートのみを開放し、アクセス元を制限します。
  • マルチテナントのデータ管理: テナントごとにデータを分離し、アクセス権限を厳格に管理します。

あとはこれらの決め事をドキュメント化しておくことと、サービスを提供する企業自体がISMSなどの第三者認証をとってセキュアな企業である証明を持っておくことも大事です。特に第三者認証については、すべてのセキュリティチェックシートであるか聞かれて、「ないんだよなあ....」と申し訳ない気持ちになってしまったので....まあ、とるのはめちゃくちゃ大変なので、最初のフェーズでやると体制的にも死ぬ気はしますが....。

終わりに

文字ばかりのこんなに長い日記を読んでくれてありがとうございます。一応企業の経営者の立場なので、間違ったこと書いてたらどうしようとビクビクしてます。その時は優しく指摘してください。お願いします。優しくですよ。

うぐいすソリューションズTechBlog
うぐいすソリューションズTechBlogPublication

株式会社うぐいすソリューションズの技術ブログです。

Discussion