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