AWS Lambda中心のB2B SaaSで、エンタープライズ対応を最小努力で進める現実解

この記事で言いたいこと

AWS Lambda中心のB2B SaaSでも、エンタープライズ対応はできます。

ただし、やる順番を間違えると地獄になります。

エンタープライズ顧客から来るセキュリティチェックシートには、だいたいこういう質問が並びます。

WAFはありますか？
通信は暗号化されていますか？
認証・認可はどう管理していますか？
操作ログは取っていますか？
監査ログはありますか？
障害監視はしていますか？
バックアップは取得していますか？
復旧手順はありますか？
脆弱性対応はどうしていますか？
インシデント対応フローはありますか？
AWSの設定変更履歴は追えますか？
セキュリティ設定の準拠状況を確認できますか？
データはどこに保存されていますか？
委託先・クラウド利用状況を説明できますか？

ここで焦って、いきなりSOC 2、ISO27001、ISMAP、専用環境、SIEM、CSPM、EDR、ペネトレーションテスト、全社ゼロトラスト……と広げると、だいたい燃えます。

まずやるべきことは、もっと地味です。

Lambda / API Gateway / WAF / CloudWatch / DynamoDB / AWS Config / CloudTrail を前提に、“今ある構成で説明できる証跡”を整えること。

エンプラ対応は、最初から巨大なセキュリティ投資をすることではありません。

最初に必要なのは、次の3つです。

何を守っているかを説明できること
何が起きたかを追えること
標準対応と有償対応の境界を決めること

この記事では、AWS Lambda中心のB2B SaaSを前提に、最小努力でエンタープライズ対応を前に進める現実解を整理します。

主に扱うAWSサービスは以下です。

AWS Lambda
Amazon API Gateway
AWS WAF
Amazon CloudWatch
Amazon DynamoDB
AWS Config
AWS CloudTrail
AWS Security Hub
AWS IAM
AWS Backup / DynamoDB PITR

対象読者は、AWSエンジニア、SRE、情シス、SaaSのPdM、Sales Engineerです。

前提：Lambda中心SaaSの典型構成

この記事では、次のような構成を想定します。

Client / Partner System / Admin UI
  ↓
Amazon API Gateway
  ↓
AWS Lambda
  ↓
Amazon DynamoDB
  ↓
Amazon S3 / 外部API / その他マスタ

周辺に以下があります。

AWS WAF
CloudWatch Logs / Metrics / Alarms
AWS Config
AWS CloudTrail
AWS IAM
Security Hub
Backup / PITR

Lambda中心のSaaSは、インフラ管理コストを小さくできます。

しかし、エンプラ対応では、こう聞かれます。

サーバレスなので安全ですか？

答えは「サーバレスだから安全」ではありません。

正しくは、

サーバ管理の一部はAWS側に委ねられるが、アプリケーション、IAM、データ、ログ、設定、監視、変更管理、責任分界点はSaaS提供者側で設計・運用する必要がある。

です。

ここを曖昧にすると、エンタープライズ商談で詰まります。

まず全体像：最小努力で進める順番

結論から言うと、優先順位はこうです。

優先	やること	目的
1	セキュリティ回答DBを作る	毎回の回答を属人化させない
2	AWS構成と証跡を棚卸しする	回答の根拠を持つ
3	API Gateway / Lambda / WAF / CloudWatchのログを整える	障害・攻撃・問い合わせを追えるようにする
4	IAM最小権限を点検する	権限過多を減らす
5	DynamoDBのバックアップ・PITRを確認する	誤削除・障害時に説明できるようにする
6	AWS Configで設定準拠を見える化する	継続監査の土台を作る
7	CloudTrailで操作履歴を説明できるようにする	誰が何をしたか追えるようにする
8	Security Hubで統制チェックを集約する	セキュリティ姿勢を継続的に見る
9	Enterpriseプラン・有償オプションに分ける	セキュリティ対応を収益化する
10	個別要件を標準化する	専用対応を増やしすぎない

ポイントは、いきなり完璧なセキュリティ体制を作ろうとしないことです。

まずは、チェックシートに対して一貫して答えられる状態を作る。
その次に、証跡を整える。
その次に、自動監査・有償オプション化へ進む。

この順番が現実的です。

AWS公式情報で押さえるべき基礎

Lambda中心のSaaSでエンプラ対応を設計するとき、最低限押さえておきたい公式情報があります。

AWS LambdaのIAMでは、AWSは認証・認可にIAMを使い、管理者がLambdaリソースへのアクセスを制御できると説明しています。また、人間ユーザーにはフェデレーションや一時的な認証情報の利用が推奨されています。
https://docs.aws.amazon.com/lambda/latest/operatorguide/least-privilege.html

AWS WAFは、IPアドレス、HTTPヘッダー、本文、URIなどの条件に基づいてWebトラフィックをフィルタリングでき、複数Webサイトへルールを展開できます。
https://aws.amazon.com/documentation-overview/waf/

API Gatewayは、CloudWatch LogsやCloudWatch Alarmsなどを使ってAPIの監視・トラブルシュートができます。AWS公式ドキュメントでは、API Gatewayのログにはexecution loggingとaccess loggingがあると説明されています。
https://docs.aws.amazon.com/apigateway/latest/developerguide/security-monitoring.html
https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-logging.html

CloudWatch Lambda Insightsは、LambdaのCPU時間、メモリ、ディスク、ネットワークなどのシステムレベルメトリクスや、cold startなどの診断情報を収集・集約できます。
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html

AWS ConfigのConformance Packは、AWS Configルールと修復アクションの集合をYAMLテンプレートとして定義し、アカウント・リージョン・Organizationsに展開できます。
https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html

CloudTrailは、AWSアカウントのAPIコール履歴を記録し、誰が、いつ、どのIPから、どのAPIを呼んだかなどを追跡できます。
https://docs.aws.amazon.com/cloudtrail/

Security Hubは、AWSリソースに対するセキュリティベストプラクティスチェックや、AWSサービス・パートナー製品からの検出結果を集約するサービスです。AWS Foundational Security Best Practicesなどの標準に対するチェックを提供します。
https://aws.amazon.com/documentation-overview/security-hub/

DynamoDBのPITRは、誤った書き込みや削除からデータを保護し、指定された復旧期間内の任意の秒に復元できます。2025年1月には、PITRの復旧期間を1〜35日で設定できるようになっています。
https://aws.amazon.com/about-aws/whats-new/2025/01/amazon-dynamodb-configurable-point-in-time-recovery-periods/

この記事の設計は、これらの前提に基づいています。

エンタープライズ対応で一番やってはいけないこと

最初にアンチパターンを潰します。

アンチパターン1：セキュリティチェックシートを営業のExcel作業にする

よくあります。

顧客からExcelが来る
↓
営業が過去回答を探す
↓
Slackで開発に聞く
↓
似た回答をコピペ
↓
提出
↓
次の顧客でまた同じことをする

これは、初期は回ります。

しかし、エンプラ商談が増えると破綻します。

回答が顧客ごとにブレる
古い回答が使い回される
証跡がない
誰が承認したか分からない
開発・情シスへの割り込みが増える
回答品質が営業担当の経験に依存する

セキュリティチェックシートは、営業の雑務ではありません。

プロダクト機能・業務基盤・証跡管理の問題です。

最初に作るべきなのは、セキュリティ回答DBです。

セキュリティ回答DBを作る

最小構成はこれです。

id: "SEC-WAF-001"
category: "network_security"
status: "approved"
version: "1.0.0"

question_patterns:
  - "WAFは導入していますか？"
  - "Webアプリケーションファイアウォールはありますか？"
  - "不正なWebリクエストへの対策はありますか？"

short_answer: "yes"

standard_answer: |
  本サービスでは、公開APIおよびWebアプリケーションの保護を目的としてAWS WAFを利用しています。
  AWS WAFにより、IPアドレス、HTTPヘッダー、URI等の条件に基づくWebリクエストの制御を行います。
  個別の顧客指定ルール、専用ルール、追加のBot対策等は、契約プランまたは有償オプションにより対応可否を確認します。

conditions:
  - "標準公開エンドポイントが対象"
  - "顧客専用ルールは標準提供範囲外"
  - "WAFログの個別提出は契約条件により確認"

evidence_refs:
  - id: "EVD-WAF-001"
    type: "system_config"
    title: "AWS WAF Web ACL設定"
    visibility: "internal_only"
  - id: "EVD-WAF-002"
    type: "aws_doc"
    title: "AWS WAF Documentation"
    url: "https://aws.amazon.com/documentation-overview/waf/"
    visibility: "public"

plan_availability:
  standard: true
  enterprise: true
  paid_option: true
  note: "個別WAFルール・追加ログ提出は有償オプション"

owner_team: "platform"
reviewer: "security@example.com"
last_reviewed_at: "2026-05-10"
next_review_due_at: "2026-08-10"

このように、回答文だけでなく、以下を持たせます。

質問パターン
標準回答
条件
証跡
プラン提供範囲
owner
reviewer
最終レビュー日
次回レビュー日

これで、セキュリティ回答が「営業の記憶」から「管理できる資産」になります。

AWS構成を証跡マップにする

次に、現在のAWSスタックを証跡マップにします。

API Gateway
  ├─ Access logs
  ├─ Execution logs
  ├─ throttling / usage plan
  └─ custom domain / TLS

Lambda
  ├─ IAM execution role
  ├─ environment variables
  ├─ timeout / memory
  ├─ CloudWatch Logs
  ├─ Lambda Insights
  └─ X-Ray / tracing if enabled

DynamoDB
  ├─ encryption at rest
  ├─ PITR
  ├─ backup policy
  ├─ access policy
  └─ table change history

WAF
  ├─ Web ACL
  ├─ managed rules
  ├─ custom rules
  ├─ rate-based rules
  └─ logs / metrics

CloudWatch
  ├─ logs
  ├─ metrics
  ├─ alarms
  ├─ dashboards
  └─ log retention

AWS Config
  ├─ recording
  ├─ rules
  ├─ conformance packs
  └─ compliance history

CloudTrail
  ├─ management events
  ├─ data events if needed
  ├─ S3 delivery
  └─ log integrity / retention

Security Hub
  ├─ standards
  ├─ findings
  ├─ severity
  └─ remediation status

エンプラ対応では、技術的に設定しているだけでは足りません。

説明できる形にする必要があります。

たとえば、WAFを使っているなら、チェックシート回答にはこう書けます。

公開APIおよびWebアプリケーションに対するWebリクエスト制御のため、AWS WAFを利用しています。標準構成ではAWS WAFのWeb ACLを適用し、必要に応じてマネージドルールやカスタムルールを設定します。顧客専用ルールや個別ログ提出は契約条件により確認します。

このとき、証跡として以下を持ちます。

WAF Web ACL設定
適用対象リソース
有効なrule group
rate-based ruleの有無
CloudWatchメトリクス
ログ設定の有無

API Gateway：エンプラ向けに最低限見るべきこと

API Gatewayは、エンプラ顧客から見ると「外部公開面」です。

最低限見るべき項目は以下です。

項目	確認内容
TLS	HTTPS通信が前提か
Custom domain	ドメイン・証明書管理
Access logging	誰がいつどのAPIを呼んだか
Execution logging	エラー調査に必要なログ
Throttling	過剰リクエストへの制御
Usage plans	APIキーや利用制御が必要か
Authorizer	認証・認可方式
WAF association	WAF適用有無
CORS	不要に広くないか
Error response	内部情報を返していないか

API Gatewayのaccess logは、最低限このような項目を出したいです。

{
  "requestId": "$context.requestId",
  "ip": "$context.identity.sourceIp",
  "requestTime": "$context.requestTime",
  "httpMethod": "$context.httpMethod",
  "resourcePath": "$context.resourcePath",
  "status": "$context.status",
  "protocol": "$context.protocol",
  "responseLength": "$context.responseLength",
  "integrationLatency": "$context.integrationLatency",
  "userAgent": "$context.identity.userAgent"
}

ただし、ログに個人情報や機密値を出しすぎないよう注意します。

チェックシート回答例です。

API GatewayではCloudWatch Logsによるアクセスログおよび実行ログを設定し、リクエストID、呼び出し元IP、HTTPメソッド、ステータスコード、レイテンシ等を確認できる構成としています。ログの保存期間および顧客別提出可否は契約条件により確認します。

Lambda：最小権限と実行ログを整える

Lambdaでまず見るべきは、IAM実行ロールです。

Lambda関数ごとに実行ロールが過剰になっていると、チェックシートで説明しづらくなります。

悪い例です。

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

エンプラ対応では、これはかなり厳しいです。

改善方針はシンプルです。

Lambdaごとに実行ロールを分ける
必要なDynamoDBテーブルだけ許可する
必要なS3 bucket / prefixだけ許可する
Secrets Manager / SSM Parameter Storeも必要範囲に絞る
本番環境と開発環境の権限を分ける
人間ユーザーに長期アクセスキーを持たせない

AWS LambdaのIAM公式ドキュメントでも、IAMによりLambdaリソースへのアクセス制御を行うこと、可能な場合は一時的な認証情報やフェデレーションを使うことが説明されています。
https://docs.aws.amazon.com/lambda/latest/operatorguide/least-privilege.html

Lambda実行ロールの例です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DynamoDBAccessForSimulationTable",
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:PutItem",
        "dynamodb:UpdateItem",
        "dynamodb:Query"
      ],
      "Resource": [
        "arn:aws:dynamodb:ap-northeast-1:123456789012:table/prod-simulation"
      ]
    },
    {
      "Sid": "CloudWatchLogsAccess",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "*"
    }
  ]
}

実務では、CloudWatch LogsのResourceを厳密に絞るか、AWS管理ポリシーとの兼ね合いも検討します。

チェックシート回答例です。

Lambda関数には用途別のIAM実行ロールを付与し、必要なAWSリソースに対して必要最小限の権限を設定する方針です。権限変更はIaCまたは管理された変更プロセスを通じて実施し、CloudTrail等によりAWS API操作履歴を確認できる構成としています。

CloudWatch：ログ・メトリクス・アラームを“証跡”にする

CloudWatchは、エンタープライズ対応でかなり重要です。

ただし、単にログがあるだけでは弱いです。

最低限、以下を整理します。

項目	見るもの
Lambda logs	エラー、処理結果、request_id
API Gateway logs	アクセス、ステータス、レイテンシ
Metrics	5xx, 4xx, latency, throttles
Alarms	重大エラー、エラー率、レイテンシ
Dashboards	運用監視画面
Log retention	保存期間
Lambda Insights	メモリ、CPU、cold startなど

Lambda Insightsは、Lambdaのランタイムパフォーマンスメトリクスやログを収集・集約し、cold startなどの診断情報も扱えます。
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html

最低限のメトリクス設計です。

API Gateway
  - 4XXError
  - 5XXError
  - Latency
  - IntegrationLatency
  - Count

Lambda
  - Errors
  - Duration
  - Throttles
  - ConcurrentExecutions
  - IteratorAge if stream/event source
  - Lambda Insights: memory / cpu / cold starts

DynamoDB
  - ThrottledRequests
  - ConsumedReadCapacityUnits
  - ConsumedWriteCapacityUnits
  - SystemErrors
  - UserErrors

チェックシート回答例です。

サービス運用に必要なログおよびメトリクスはAmazon CloudWatchに集約し、APIエラー、Lambdaエラー、レイテンシ、スロットリング等を監視しています。重要な異常についてはCloudWatch Alarm等により検知できる構成としています。ログ保存期間や顧客別ログ提出は契約条件により確認します。

ここで重要なのは、顧客にログを出せるかどうかは別問題ということです。

ログを取得していることと、顧客に提出できることは違います。

この2つを混ぜると契約リスクになります。

DynamoDB：バックアップとPITRを説明可能にする

DynamoDBでエンプラ対応時によく聞かれるのは、バックアップと復旧です。

最低限、次を確認します。

項目	確認内容
PITR	有効か
復旧可能期間	何日か
On-demand backup	使うか
Backup policy	どのテーブルが対象か
削除保護	重要テーブルで有効か
暗号化	AWS managed keyかKMS CMKか
アクセス権限	Lambda / 管理者の権限
テーブル変更履歴	CloudTrail / Configで追えるか
データ削除	顧客退会時の扱い

DynamoDBのPITRは、誤った書き込みや削除から保護し、復旧期間内の任意の秒に復元できます。2025年1月時点で、PITRの復旧期間は1〜35日で設定可能です。
https://aws.amazon.com/about-aws/whats-new/2025/01/amazon-dynamodb-configurable-point-in-time-recovery-periods/

チェックシート回答例です。

主要な業務データを格納するDynamoDBテーブルについては、必要に応じてPoint-in-Time Recovery（PITR）やバックアップ機能を利用し、誤操作や障害時の復旧に備える構成としています。復旧対象、復旧可能期間、顧客単位の復元可否はシステム構成および契約条件により異なります。

ここでも言い切りすぎないことが重要です。

「バックアップがあります」とだけ書くと、顧客は自社データだけを即時復元できると思うかもしれません。

実際には、テーブル単位復元、アプリケーション整合性、顧客単位復元、RTO/RPOで話が変わります。

回答には条件を書きます。

AWS Config：セキュリティ設定を継続的に見る

AWS Configは、エンプラ対応の証跡化でかなり使えます。

特に、以下のような質問への回答根拠になります。

セキュリティ設定を継続的に確認していますか？
リソース設定の変更履歴は追えますか？
準拠状況を確認できますか？
設定変更を検知できますか？

AWS ConfigのConformance Packは、Configルールと修復アクションの集合をYAMLテンプレートとして定義し、アカウント・リージョン・Organizationsへ展開できます。
https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html

最初に見るべきConfigルールの例です。

- cloudtrail-enabled
- cloudwatch-log-group-encrypted
- dynamodb-pitr-enabled
- dynamodb-table-encrypted-kms
- iam-policy-no-statements-with-admin-access
- lambda-function-public-access-prohibited
- lambda-inside-vpc
- api-gw-execution-logging-enabled
- s3-bucket-public-read-prohibited
- s3-bucket-server-side-encryption-enabled

実際にどのManaged Ruleが使えるか、リージョンやサービス対応は確認が必要です。
重要なのは、自社の標準チェックセットを持つことです。

Conformance Packのイメージです。

Resources:
  DynamoDBPITREnabled:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: dynamodb-pitr-enabled
      Source:
        Owner: AWS
        SourceIdentifier: DYNAMODB_PITR_ENABLED

チェックシート回答例です。

AWSリソースの一部についてはAWS Configにより設定変更や準拠状況を確認できる構成としています。必要に応じてConfigルールやConformance Packを利用し、重要なセキュリティ設定の継続的な確認を行います。対象ルールや適用範囲は環境により異なります。

Configは“やっている感”ではなく、準拠状況の証跡化に使います。

CloudTrail：誰が何をしたかを追えるようにする

CloudTrailは、エンタープライズ対応でかなり聞かれます。

顧客が知りたいのは、

AWS上の操作履歴を追えるか
管理者操作を記録しているか
設定変更を追跡できるか
インシデント時に調査できるか

です。

CloudTrailは、AWSアカウントのAPIコール履歴を記録し、ユーザー、時刻、送信元IP、リクエストパラメータ、レスポンス要素などを含む情報を記録できます。
https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/Welcome.html

チェックシート回答例です。

AWS環境における管理操作やAPIコールの履歴はAWS CloudTrailにより記録され、必要に応じて操作主体、実行時刻、送信元IP、対象API等を確認できる構成としています。ログの保存期間、対象イベント、顧客別提出可否は契約条件および運用方針により異なります。

ここで注意があります。

CloudTrailはAWS API操作履歴です。
アプリケーション内のユーザー操作ログとは別です。

両者を混同してはいけません。

ログ	例
CloudTrail	IAM変更、Lambda更新、DynamoDB設定変更
Application Audit Log	顧客ユーザーがログインした、試算を作成した、データを削除した
API Gateway Access Log	どのAPIエンドポイントが呼ばれた
Lambda Application Log	処理エラー、業務処理結果

チェックシートでは、どのログの話かを必ず分けます。

Security Hub：最小努力で“継続チェック”を見せる

Security Hubは、エンタープライズ向けに「AWS環境のセキュリティ姿勢を継続的に見ている」と説明しやすいサービスです。

Security Hubは、AWSリソースへのセキュリティベストプラクティスチェックや、GuardDuty、Inspector、Macie、AWS Config等の検出結果を標準形式で集約するサービスです。
https://aws.amazon.com/documentation-overview/security-hub/

Security Hub CSPMでは、AWS Foundational Security Best Practicesなどのセキュリティ標準を有効にすると、標準に含まれるcontrolsに対してセキュリティチェックが実行され、findingsやsecurity scoreが生成されます。
https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards.html

チェックシート回答例です。

AWS環境のセキュリティベストプラクティス確認には、必要に応じてAWS Security Hubを利用し、AWS Foundational Security Best Practices等の標準に基づく検出結果を確認します。検出結果はリスクに応じて優先順位付けし、改善対応を行います。

Security Hubは万能ではありません。

ただし、最小努力で次を実現できます。

セキュリティチェック結果の集約
準拠状況の可視化
優先度付け
監査・説明材料
改善タスクの起点

特に、エンプラチェックシートで「継続的なセキュリティ確認をしていますか？」と聞かれたときに、かなり使いやすいです。

WAF：標準対応と有償対応を分ける

AWS WAFは、エンプラ商談で説明しやすい一方で、提供範囲を間違えると危険です。

標準回答ではこう言えます。

標準公開エンドポイントにはAWS WAFを適用し、Webリクエストに対する基本的な制御を行っています。

ただし、次は標準とは限りません。

顧客専用WAFルール
顧客指定IP許可・拒否
WAFログの定期提出
Bot Controlなど追加機能
専用Web ACL
顧客別レート制限
SOC / SIEM連携
攻撃レポート提出

これは有償オプション候補です。

対応	標準	Enterprise	有償オプション
標準WAF適用	✅	✅	-
AWS Managed Rules	✅	✅	-
顧客別IP制限	-	条件付き	✅
顧客別WAFルール	-	-	✅
WAFログ提出	-	条件付き	✅
Bot Control	-	条件付き	✅
SIEM連携	-	-	✅

セキュリティ機能は、全部無料にしない方がいいです。

標準で守るべきものと、顧客固有要件として有償化するものを分けます。

Lambda中心SaaSのエンタープライズ対応チェックリスト

ここからは実務チェックリストです。

1. API Gateway

HTTPS/TLS前提になっている
Access loggingを設定している
Execution loggingの扱いを決めている
ログに機密値を出していない
WAFを適用している
4xx / 5xx / latencyを監視している
throttling設定を確認している
認証・認可方式を説明できる
CORSが広すぎない
custom domain / 証明書管理を説明できる

2. Lambda

実行ロールが過剰権限でない
関数ごとの責務が分かれている
環境変数に秘密情報を直書きしていない
Secrets Manager / SSM Parameter Storeの利用方針がある
CloudWatch Logsに出力している
エラー率・Duration・Throttlesを監視している
timeout / memoryが適切
Lambda Insightsの利用可否を検討している
本番・開発環境の分離がある
デプロイ履歴を追える

3. DynamoDB

重要テーブルでPITRを有効化している
バックアップ対象を定義している
削除保護を検討している
暗号化方式を説明できる
IAM権限を必要最小限にしている
テーブル設計とtenant分離を説明できる
誤削除・誤更新時の復旧方針がある
顧客単位復旧の可否を明確にしている

4. WAF

Web ACLを適用している
Managed Rulesの利用状況を把握している
rate-based ruleを検討している
WAFログ取得方針がある
顧客別ルールの標準/有償境界がある
誤検知時の対応フローがある

5. CloudWatch

API Gateway logsを見られる
Lambda logsを見られる
重要メトリクスにAlarmを設定している
log retentionを設定している
dashboardがある
障害調査でrequest_idを追える
顧客提出可能なログ範囲を決めている

6. Config

AWS Configを有効化している
対象リソースを定義している
重要Config Rulesを設定している
Conformance Packを検討している
非準拠リソースの対応フローがある
証跡として出せるレポートを整理している

7. CloudTrail

管理イベントを記録している
保存先と保持期間を決めている
CloudTrailログへのアクセス権限を制御している
重要操作の調査手順がある
アプリケーション監査ログとCloudTrailを混同していない

8. Security Hub

Security Hub有効化を検討している
AWS Foundational Security Best Practicesを確認している
findingsのtriageフローがある
対応済み・例外・保留を管理している
定期レビューの場がある

セキュリティチェックシート回答テンプレート

実務で使える回答テンプレートを置きます。

WAF

本サービスでは、公開APIおよびWebアプリケーションへの不正なWebリクエスト対策としてAWS WAFを利用しています。標準構成ではWeb ACLを適用し、必要に応じてAWS Managed Rulesやレートベースルール等を利用します。顧客専用のWAFルール、ログ提出、追加のBot対策等は契約プランまたは有償オプションとして対応可否を確認します。

ログ監視

API Gateway、Lambda等の実行ログおよびメトリクスはAmazon CloudWatchに集約し、エラー、レイテンシ、スロットリング等の監視に利用しています。重要な異常についてはCloudWatch Alarm等により検知できる構成としています。ログ保存期間および顧客別ログ提出可否は契約条件により異なります。

AWS操作履歴

AWS環境における管理操作およびAPIコール履歴はAWS CloudTrailにより記録し、必要に応じて操作主体、実行時刻、送信元IP、対象API等を確認できる構成としています。アプリケーション上のユーザー操作ログとは別管理となります。

バックアップ

主要データストアについては、サービス特性に応じてバックアップまたはPoint-in-Time Recovery等を利用し、誤操作や障害時の復旧に備えています。復旧対象、復旧可能期間、顧客単位の復元可否、RTO/RPOはシステム構成および契約条件により異なります。

設定準拠確認

AWSリソースの一部についてはAWS Configにより設定変更や準拠状況を確認できる構成としています。必要に応じてConfig RulesやConformance Packを利用し、重要なセキュリティ設定の継続的な確認を行います。

脆弱性・セキュリティ姿勢

AWS環境のセキュリティベストプラクティス確認には、必要に応じてAWS Security Hub等を活用し、検出結果をリスクに応じて確認・改善する運用を行います。個別の監査レポート提出や顧客指定基準への適合確認は契約条件により確認します。

IAM

AWSリソースへのアクセス権限はIAMにより管理し、用途に応じたロール・ポリシーを設定しています。Lambda関数には必要なAWSリソースへのアクセス権限を付与し、不要な権限を持たせない方針です。人間ユーザーのアクセス管理、権限レビュー、特権操作の扱いは社内運用に基づき管理します。

有償オプション化すべきもの

エンプラ対応では、標準対応と有償対応を分けないと、強い顧客ほど無償対応が増えます。

有償オプションにしやすいものは以下です。

オプション	内容
個別セキュリティチェック対応	顧客指定フォーマットへの回答
セキュリティ説明会	情シス・監査部門向け説明
WAF個別ルール	顧客専用IP制限・ルール
監査ログエクスポート	顧客向け監査証跡出力
長期ログ保管	標準期間を超える保管
個別SLA	可用性・復旧条件の個別契約
専用環境	tenant分離を強めた構成
専用バックアップ	顧客別要件に応じたバックアップ
Security Hub / Configレポート提出	定期レポート化
脆弱性診断レポート提出	NDA前提の個別提出

これをプランにします。

Standard
  - 標準WAF
  - 標準ログ監視
  - 標準バックアップ
  - 標準セキュリティ回答

Enterprise
  - SSO
  - IP制限
  - 監査ログ閲覧
  - セキュリティチェック優先対応
  - 証跡資料のNDA前提提示

Paid Option
  - 個別WAFルール
  - 個別ログ提出
  - 長期ログ保管
  - セキュリティ説明会
  - 専用環境
  - 個別SLA

セキュリティはコストではあります。

でも、エンプラ顧客にとっては購買条件です。
つまり、価格に転嫁できる価値でもあります。

“最小努力”で進める90日ロードマップ

0〜30日：回答できる状態にする

過去チェックシートを集める
頻出質問を50件に絞る
セキュリティ回答DBを作る
AWS構成図を更新する
WAF / CloudWatch / DynamoDB / Config / CloudTrailの証跡を棚卸しする
チェックシート回答テンプレートを作る

この段階のゴールは、回答速度と一貫性です。

31〜60日：証跡を整える

API Gateway access logを確認
Lambda log / metrics / alarmを確認
DynamoDB PITRを確認
CloudTrail設定を確認
AWS Configの基本ルールを確認
Security Hubの導入可否を確認
証跡リポジトリを作る
回答DBにevidence_refsを紐づける

この段階のゴールは、言ったことの根拠を持つことです。

61〜90日：プラン化する

Standard / Enterprise / Paid Optionを整理
顧客別セキュリティ要件を分類
有償オプション価格を決める
セキュリティ説明資料を作る
Sales Engineer向けFAQを作る
チェックシート対応SLAを決める
回答DBのレビュー期限運用を始める

この段階のゴールは、セキュリティ対応を収益化することです。

実装例：セキュリティ回答DBのディレクトリ構成

security/
  answers/
    sec-waf-001.yaml
    sec-cloudwatch-001.yaml
    sec-dynamodb-backup-001.yaml
    sec-cloudtrail-001.yaml
    sec-config-001.yaml

  evidence/
    evidence-index.yaml

  schemas/
    security-answer.schema.json
    evidence.schema.json

  generated/
    checklist-template.md
    enterprise-security-faq.md

  scripts/
    validate-security-answers.mjs
    generate-faq.mjs

  .github/
    workflows/
      validate-security-answers.yml

回答DBは最初からSaaS化しなくていいです。

YAML + GitHub + CIで十分始められます。

実装例：証跡インデックス

id: "EVD-CLOUDWATCH-001"
title: "CloudWatch Logs and Alarms"
type: "system_config"
service:
  - "Amazon CloudWatch"
  - "AWS Lambda"
  - "Amazon API Gateway"
visibility: "internal_only"
owner_team: "platform"
updated_at: "2026-05-10"
description: |
  API GatewayおよびLambdaのログ・メトリクス・アラーム設定を確認するための証跡。
related_answers:
  - "SEC-LOG-001"
  - "SEC-MON-001"

証跡本体は、Box、Google Drive、S3、Confluenceなどアクセス制御された場所に置きます。

回答DBには参照だけ持たせます。

実装例：レビュー期限切れ検知

import fs from "node:fs";
import { globSync } from "glob";
import YAML from "yaml";

const today = new Date();
let hasExpired = false;

for (const file of globSync("security/answers/**/*.yaml")) {
  const doc = YAML.parse(fs.readFileSync(file, "utf8"));

  if (!doc.next_review_due_at) {
    console.error(`❌ ${file}: next_review_due_at is missing`);
    hasExpired = true;
    continue;
  }

  const due = new Date(doc.next_review_due_at);

  if (due < today && doc.status === "approved") {
    console.error(`❌ ${file}: review expired at ${doc.next_review_due_at}`);
    hasExpired = true;
  }
}

if (hasExpired) {
  process.exit(1);
}

セキュリティ回答は陳腐化します。

「昔は正しかった」が一番怖いです。

レビュー期限をCIで落とすだけでも、かなり運用が締まります。

よくある質問

Q. Lambda中心だとエンタープライズ対応は弱いですか？

弱いとは限りません。むしろ、運用するサーバを減らせる点では有利な面もあります。ただし、IAM、ログ、監視、データ保護、設定変更履歴、責任分界点を説明できなければ、サーバレスであることはエンプラ対応の根拠になりません。

Q. AWS WAFを入れていれば十分ですか？

十分ではありません。WAFはWebリクエスト保護の一部です。認証、認可、ログ、監視、バックアップ、脆弱性対応、インシデント対応、データ管理などは別途必要です。

Q. CloudWatch Logsがあれば監査ログと言えますか？

言い切らない方が安全です。CloudWatch Logsはアプリケーションログや実行ログの保管先として使えますが、顧客向けの監査ログや操作証跡として提供できるかは、ログ設計、保存期間、tenant分離、マスキング、契約条件によります。

Q. CloudTrailとアプリケーション監査ログは違いますか？

違います。CloudTrailはAWS API操作履歴です。アプリケーション内で顧客ユーザーが何をしたかを記録するには、別途アプリケーション監査ログが必要です。

Q. AWS Configを有効化すればコンプライアンス対応は完了ですか？

完了ではありません。ConfigはAWSリソース設定の記録・評価に役立ちますが、規程、運用、レビュー、例外管理、改善対応が必要です。Configは証跡化と継続監視の土台です。

Q. Security Hubを入れるべきですか？

エンタープライズ対応を進めるなら、優先度は高いです。Security Hubにより、AWS Foundational Security Best Practicesなどの標準に基づくチェックや findings の集約ができます。ただし、導入して終わりではなく、findingsのtriageと改善フローが必要です。

Q. どこから有償オプションにすべきですか？

顧客固有性が高く、人的工数や契約責任が重いものから有償化しやすいです。個別チェックシート対応、個別WAFルール、監査ログエクスポート、長期ログ保管、セキュリティ説明会、個別SLA、専用環境などが候補です。

まとめ：Lambda中心SaaSのエンプラ対応は、巨大投資より“説明可能な証跡化”から始める

AWS Lambda中心のB2B SaaSでも、エンタープライズ対応は進められます。

ただし、最初から巨大なセキュリティ体制を作る必要はありません。

まずやるべきことは、地味です。

セキュリティ回答DBを作る
AWS構成を証跡マップにする
API Gatewayのログを整える
LambdaのIAMとログを点検する
DynamoDBのバックアップ・PITRを確認する
CloudWatchで監視を見える化する
CloudTrailでAWS操作履歴を追えるようにする
AWS Configで設定準拠を確認する
Security Hubでセキュリティ姿勢を集約する
標準対応と有償オプションを分ける

エンプラ対応で大事なのは、「何となく安全です」と言わないことです。

何を守っているか。
どの範囲が標準か。
どこから有償か。
どの証跡で説明できるか。
何が未対応か。
誰がレビューしたか。
いつ見直すか。

ここまで持てると、セキュリティチェックシートは営業の雑務ではなくなります。

エンタープライズ商談を前に進めるプロダクト機能になります。

Lambda、API Gateway、WAF、CloudWatch、DynamoDB、Config、CloudTrail、Security Hub。
すでにあるAWSスタックを、ただのインフラではなく、説明可能な信頼の部品として再設計する。

これが、Lambda中心B2B SaaSでエンタープライズ対応を最小努力で進める現実解です。

参考リンク

AWS Lambda IAM / least privilege
https://docs.aws.amazon.com/lambda/latest/operatorguide/least-privilege.html
AWS WAF Documentation
https://aws.amazon.com/documentation-overview/waf/
API Gateway logging and monitoring
https://docs.aws.amazon.com/apigateway/latest/developerguide/security-monitoring.html
API Gateway CloudWatch logging
https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-logging.html
CloudWatch Lambda Insights
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html
AWS Config Conformance Packs
https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html
AWS CloudTrail Documentation
https://docs.aws.amazon.com/cloudtrail/
AWS CloudTrail API Reference
https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/Welcome.html
AWS Security Hub Documentation
https://aws.amazon.com/documentation-overview/security-hub/
Security Hub standards
https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards.html
DynamoDB configurable PITR
https://aws.amazon.com/about-aws/whats-new/2025/01/amazon-dynamodb-configurable-point-in-time-recovery-periods/
太陽光・蓄電池経済効果シミュレーションSaaS・API　エネがえる
https://www.enegaeru.com