AWS Security Agentで設計書とコードをレビューさせてみた

# ユーザー管理APIシステム設計書
## 1. システム概要
本システムは、ユーザー情報を管理するためのREST APIを提供します。
AWS上にサーバーレスアーキテクチャで構築します。
## 2. アーキテクチャ
[クライアント] --> [API Gateway] --> [Lambda] --> [DynamoDB]

### 2.1 使用サービス
- Amazon API Gateway: REST API エンドポイント
- AWS Lambda: ビジネスロジック実行
- Amazon DynamoDB: ユーザーデータ保存

## 3. API設計
### 3.1 エンドポイント一覧
| メソッド | パス | 説明 |
|---------|------|------|
| POST | /users | ユーザー作成 |
| GET | /users/{userId} | ユーザー取得 |
| GET | /users | ユーザー一覧取得 |
| DELETE | /users/{userId} | ユーザー削除 |

### 3.2 認証・認可
**本システムでは認証・認可機能は実装しません。**
APIは公開エンドポイントとして動作し、誰でもアクセス可能です。

> ⚠️ セキュリティ上の懸念: 認証なしでユーザーデータにアクセス可能

## 4. データモデル
### 4.1 ユーザーテーブル (Users)
| 属性名 | 型 | 説明 |
|--------|-----|------|
| userId | String (PK) | ユーザーID |
| email | String | メールアドレス |
| password | String | パスワード（平文保存） |
| creditCardNumber | String | クレジットカード番号 |
| ssn | String | 社会保障番号 |
| createdAt | String | 作成日時 |

> ⚠️ セキュリティ上の懸念: パスワードを平文で保存
### 4.2 DynamoDB設定

- **暗号化**: 無効（コスト削減のため）
- **バックアップ**: 無効
- **削除保護**: 無効
- **ポイントインタイムリカバリ**: 無効

## 5. Lambda関数設計

### 5.1 実行ロール権限

Lambda関数には以下のIAMポリシーをアタッチします：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

> ⚠️ セキュリティ上の懸念: 最小権限の原則に違反

### 5.2 環境変数

Lambda関数の環境変数には以下を設定：

- `DB_TABLE_NAME`: DynamoDBテーブル名
- `API_SECRET_KEY`: 外部APIの秘密鍵 (ハードコード)
- `ADMIN_PASSWORD`: 管理者パスワード

## 6. ログ設計
### 6.1 CloudWatch Logs

以下の情報をログに出力します：
- リクエスト全体（ヘッダー含む）
- ユーザーパスワード（デバッグ用）
- クレジットカード情報
- エラースタックトレース

> ⚠️ セキュリティ上の懸念: 機密情報がログに出力される

## 7. エラーハンドリング

エラー発生時は詳細なスタックトレースと内部情報をクライアントに返却します。
これによりデバッグが容易になります。

{
  "error": "DatabaseError",
  "message": "Connection failed to prod-database.example.com",
  "stack": "Error: Connection failed\n    at Database.connect...",
  "internalConfig": {
    "host": "prod-database.example.com",
    "user": "admin",
    "password": "SuperSecret123!"
  }
}

## 8. デプロイ
### 8.1 認証情報管理
AWSアクセスキーはソースコードに直接記述します：

const awsConfig = {
  accessKeyId: 'AKIAIOSFODNN7EXAMPLE',
  secretAccessKey: 'wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY',
  region: 'ap-northeast-1'
};

### 8.2 API Gateway設定

- **CORS**: すべてのオリジンを許可 (`*`)
- **レート制限**: 無効
- **WAF**: 未設定

PoC Design Review 指摘事項まとめ
ステータス概要
総項目数: 10
- 非準拠 (NON_COMPLIANT): 9
- 該当なし (NOT_APPLICABLE): 1

詳細レポート
1. Secret Protection Best Practices (シークレット保護)
ステータス: ❌ 非準拠
指摘内容:
- AWSのアクセスキーとシークレットキーがソースコードにハードコードされている。
- API_SECRET_KEY がLambdaの環境変数に平文で設定されている。
- パスワードや機密データがCloudWatchログに出力されている。
- エラーレスポンスに内部の認証情報が含まれている。
改善案:
- AWS Secrets ManagerまたはParameter Storeを使用する。
- ハードコードされた認証情報を削除する。
- 機密データのログ出力を停止し、エラーレスポンスをサニタイズ（無害化）する。

2. Audit Logging Best Practices (監査ログ)
ステータス: ❌ 非準拠

指摘内容:
- ログにパスワード、クレジットカード番号、APIキーなどの機密情報が含まれており、監査を妨げている。

改善案:
- ログからすべての機密データを削除する。
- 機密値を露出させずに、主要なイベント（認証、認可、データアクセス）を記録する構造化ログを実装する。

3. Authentication Best Practices (認証)
ステータス: ❌ 非準拠

指摘内容:
- 認証・認可が実装されていないため、すべてのAPIエンドポイントがパブリックにアクセス可能である。
- ユーザー管理システムであるにもかかわらず、呼び出し元の身元を確認していない。

改善案:
- AWS Cognito、API Gatewayオーソライザー、またはAPIキーを使用した認証を実装する。
- ユーザーが自分のデータにのみアクセスできるように認可制御を追加する。

4. Log Protection Best Practices (ログ保護)
ステータス: ❌ 非準拠

指摘内容:
- ユーザーのパスワード、クレジットカード番号、APIシークレットキーをCloudWatch Logsに明示的に記録する設計になっている。

改善案:
- ログのサニタイズ処理を実装し、機密データを削除してからCloudWatchに書き込む。
- 認証情報の明示的なログ出力を設計から削除する。

5. Trusted Cryptography Best Practices (信頼できる暗号化)
ステータス: ❌ 非準拠

指摘内容:
- パスワードがハッシュ化されず、平文（プレーンテキスト）で保存されている。
- DynamoDBの暗号化が明示的に無効化されている。

改善案:
- パスワードを保存する前に、bcrypt、scrypt、Argon2などの強力なアルゴリズムでハッシュ化する。
- AWS KMSを使用したDynamoDBの保存時暗号化（Encryption at rest）を有効にする。

6. Information Protection Best Practices (情報保護)
ステータス: ❌ 非準拠

指摘内容:
- 高度な機密データ（パスワード、クレジットカード番号、SSN）を扱っているにもかかわらず、平文保存、暗号化無効、シークレットのハードコード、ログ出力を行っている。

改善案:
- パスワードのハッシュ化、DynamoDBの暗号化、Secrets Managerの使用を徹底する。
- ログから機密データを削除する。
- クレジットカード情報やSSNは暗号化するか、可能であれば保持しないようにする。

7. Privileged Access Best Practices (特権アクセス)
ステータス: ❌ 非準拠

指摘内容:
- Lambda関数に *:*（すべてのリソースに対するすべてのアクション）という過剰なIAM権限が付与されている。
- 管理者パスワード（ADMIN_PASSWORD）が環境変数に保存されている。

改善案:
- LambdaのIAMロールを、必要なDynamoDBアクションのみに制限する（最小権限の原則）。
- 管理者クレデンシャルはSecrets Managerを使用する。

8. Secure by Default Best Practices (デフォルトのセキュリティ)
ステータス: ❌ 非準拠

指摘内容:
- DynamoDBの暗号化、認証、認可、APIレート制限などのセキュリティ機能がデフォルトで無効化されている。
- CORSのワイルドカード設定や、フルアクセスのLambda権限など、設定が過剰に許可されている。

改善案:
- デフォルトですべてのセキュリティ機能を有効にする。
- CORS設定を制限し、最小権限のIAMポリシーを適用する。

9. Authorization Best Practices (認可)
ステータス: ❌ 非準拠

指摘内容:
- 認証・認可を実装しない方針となっており、誰でも機密データの読み取り、変更、削除が可能である。

改善案:
- ユーザーの本人確認と権限に基づいたアクセス制御を実装する。
- ユーザーは自分のデータのみ操作可能にし、管理操作は分離する。

10. Tenant Isolation Best Practices (テナント分離)
ステータス: ⚪ 該当なし (NOT_APPLICABLE)

理由:
- このアプリケーションはマルチテナントとして設計されていないため、テナント分離の制御は適用されない。

1. 機密情報のハードコードと露出（最も深刻）
AWSのアクセスキー、DBパスワード、APIキー（Stripe, Slack等）、SSH鍵、JWTシークレットなどが、至る所に直書き（ハードコード）され、外部から見える状態になっています。

ソースコード内: 変数として直接記述されている。
CloudFormation: スタックの「説明（Description）」や「出力（Outputs）」に管理者パスワードなどが含まれており、AWSコンソールから誰でも閲覧可能。
Lambda環境変数: AWSクレデンシャルやDBパスワードが平文で設定されている。

2. 不適切なログ出力とデータ漏洩
ログに記録してはいけない情報が、サニタイズ（マスキング）されずにそのまま出力されています。
機密情報のログ出力: パスワード、クレジットカード番号、SSN（社会保障番号）、認証トークン、APIキーなどがCloudWatch Logsやコンソールログに出力されている。
エラー情報の露出: エラーレスポンスに、内部構成（DBテーブル名、スタックトレース）や認証情報が含まれており、攻撃者のヒントになっている。

3. データ保護と暗号化の欠如
保存データおよび通信データの保護が全くなされていません。
DynamoDB: 暗号化、バックアップ、削除保護がすべて「無効」になっている。
パスワード保存: ユーザーのパスワードがハッシュ化されず、平文（Plaintext）で保存されている。
PII（個人情報）: クレジットカード情報やSSNが暗号化されず平文で扱われている。

4. 監視設定とコンプライアンス違反
セキュリティ監視が機能していない、またはコンプライアンス（PCI-DSS, GDPR等）に違反する設定になっています。

API Gateway: ログ出力が完全に「OFF」になっており、追跡が不可能。
ログ保持期間: 無期限（Infinite）に設定されており、適切なライフサイクル管理ができていない。

# 推奨される次のアクション
レビューアは、「直ちに以下の対応を行うこと」を強く推奨しています。

- ハードコードの全削除: すべての機密情報をコードから削除し、AWS Secrets Manager や Parameter Store に移行する。
- ログの修正: 機密情報をログに出さないようフィルタリング処理を実装し、既存のログからは機密情報を削除する。
- 暗号化の有効化: DynamoDBのKMS暗号化を有効にし、パスワードは必ずハッシュ化して保存する。
- 最小権限の徹底: IAMロールを見直し、不要な強い権限（管理者権限など）を剥奪する。