はじめに
セキュリティは後付けではなく、根本から設計する必要があります。 多層防御 は複数の保護層を意味します。1 つの層がバイパスされた場合、次の層が保護します。
1. 多層防御モデル
Layer 1: Edge/Perimeter
┌────────────────────────────────────────┐
│ WAF, DDoS Protection, CDN │
│ Rate Limiting, IP Filtering │
└────────────────────┬───────────────────┘
│
Layer 2: Network
┌────────────────────┼───────────────────┐
│ VPC, Subnets, Security Groups │
│ Network ACLs, Private endpoints │
└────────────────────┬───────────────────┘
│
Layer 3: Application
┌────────────────────┼───────────────────┐
│ Authentication, Authorization │
│ Input Validation, CSRF/XSS protection │
└────────────────────┬───────────────────┘
│
Layer 4: Data
┌────────────────────┼───────────────────┐
│ Encryption at rest, in transit │
│ Key management, Data masking │
└────────────────────┬───────────────────┘
│
Layer 5: Monitoring
┌────────────────────┼───────────────────┐
│ Audit logs, Anomaly detection │
│ SIEM, Incident response │
└────────────────────────────────────────┘
2. 認証と認可
2.1 OAuth 2.0 + OpenID Connect
Authorization Code Flow:
User → App: "Login with Google"
App → Google: Redirect (client_id, redirect_uri, scope)
User → Google: Login + Consent
Google → App: Authorization Code
App → Google: Exchange code for tokens (+ client_secret)
Google → App: access_token + id_token (JWT)
App → API: Request + access_token
Tokens:
Access Token: Ngắn hạn (15 phút), dùng gọi API
Refresh Token: Dài hạn (7 ngày), dùng lấy access token mới
ID Token: User info (name, email), JWT format
2.2 JWT アーキテクチャ
JWT = Header.Payload.Signature
Header: { "alg": "RS256", "typ": "JWT" }
Payload: { "sub": "user-123", "role": "admin", "exp": 1705312200 }
Signature: RS256(header + payload, private_key)
Verification:
API Gateway nhận JWT
→ Verify signature bằng public key
→ Check expiration
→ Extract claims (user_id, roles)
→ Forward request + claims to services
Stateless: Không cần query database mỗi request
Revocation: Khó! (dùng short expiry + blacklist)
2.3 RBAC 対 ABAC
RBAC (Role-Based Access Control):
User → Role → Permissions
Role: "editor"
Permissions: [create_post, edit_post, delete_own_post]
Check: user.role == "editor" && action == "edit_post"
Simple, widely used
Limitation: Không handle complex policies
ABAC (Attribute-Based Access Control):
Policy based on attributes of User, Resource, Action, Environment
Policy: "User can edit post IF:
user.department == post.department AND
user.clearance >= post.classification AND
time.now BETWEEN 9:00 AND 18:00"
Flexible, fine-grained
Complex to manage
3. ネットワークセキュリティ
3.1 VPC アーキテクチャ
┌──────────────────────────────────────────────┐
│ VPC (10.0.0.0/16) │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ Public Subnet (10.0.1.0/24) │ │
│ │ ┌──────────┐ ┌──────────┐ │ │
│ │ │ ALB │ │ NAT GW │ │ │
│ │ └──────────┘ └──────────┘ │ │
│ └──────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ Private Subnet (10.0.2.0/24) │ │
│ │ ┌──────────┐ ┌──────────┐ │ │
│ │ │ App │ │ App │ │ │
│ │ │ Server │ │ Server │ │ │
│ │ └──────────┘ └──────────┘ │ │
│ └──────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ Isolated Subnet (10.0.3.0/24) │ │
│ │ ┌──────────┐ ┌──────────┐ │ │
│ │ │ Database │ │ Redis │ │ │
│ │ └──────────┘ └──────────┘ │ │
│ └──────────────────────────────────────────┘ │
└──────────────────────────────────────────────┘
Security Groups:
ALB: Inbound 443 from 0.0.0.0/0
App: Inbound 8080 from ALB SG only
DB: Inbound 5432 from App SG only
3.2 WAF (ウェブアプリケーションファイアウォール)
WAF Rules:
- Block SQL injection patterns
- Block XSS payloads
- Rate limit: Max 1000 req/min per IP
- Geo blocking: Block countries không phục vụ
- Bot detection: Block scrapers, bad bots
- Custom rules: Block specific URLs/patterns
Traffic flow:
Internet → CloudFlare/WAF → ALB → App
Attack blocked at edge (trước khi đến app)
4. データセキュリティ
4.1 暗号化
In Transit:
Client ←── TLS 1.3 ──→ Server
Service A ←── mTLS ──→ Service B
App ←── TLS ──→ Database
At Rest:
Database: AES-256 encrypted storage
S3: Server-side encryption (SSE-S3, SSE-KMS)
Disk: LUKS / BitLocker
Key Management:
❌ Hardcode keys trong code
❌ Lưu keys trong database
✅ KMS (AWS KMS, HashiCorp Vault)
✅ Envelope encryption:
Master Key (KMS) → encrypts → Data Key
Data Key → encrypts → Data
Rotate Data Key dễ dàng
4.2 データの分類
Level 1 - Public: Marketing content, public APIs
Level 2 - Internal: Internal docs, employee directory
Level 3 - Confidential: Customer PII, financial data
Level 4 - Restricted: Passwords, encryption keys, PHI
Mỗi level có controls khác nhau:
Level 4: Encrypted + access log + MFA + need-to-know
Level 1: No special controls
5. API セキュリティ
1. Authentication: Ai đang gọi?
API Key, OAuth2 Bearer Token, mTLS
2. Authorization: Được phép gọi endpoint này?
RBAC/ABAC check per endpoint
3. Input Validation: Data có hợp lệ?
Schema validation, sanitize input
4. Rate Limiting:
Per user: 100 req/min
Per IP: 1000 req/min
Per endpoint: /login → 5 req/min (brute force)
5. Request Size Limit:
Max body: 10MB
Max header: 8KB
6. Output Filtering:
Không trả về sensitive fields
Mask PII in logs
6. ゼロトラストアーキテクチャ
Traditional (Castle & Moat):
┌─────────────────────────┐
│ Trusted Network │
│ Everything inside = OK │ ← Flat network
│ Firewall at perimeter │ Once in, full access
└─────────────────────────┘
Zero Trust:
"Never trust, always verify"
"Assume breach"
Principles:
1. Verify explicitly (every request)
2. Least privilege access
3. Assume breach
Implementation:
┌───────────────────────────────────────┐
│ Every request verified: │
│ - Identity (who?) │
│ - Device health (patched? compliant?) │
│ - Location (expected?) │
│ - Data sensitivity (what access?) │
│ - Anomaly detection (normal pattern?) │
└───────────────────────────────────────┘
Service Mesh (mTLS): Service ↔ Service encrypted + authenticated
Identity-aware proxy: Google BeyondCorp style
概要
| レイヤー | コントロール |
|---|---|
| エッジ | WAF、DDoS、CDN、レート制限 |
| ネットワーク | VPC、セキュリティグループ、プライベートサブネット |
| アプリケーション | AuthN/AuthZ、入力検証、CSRF |
| データ | 暗号化、鍵管理、分類 |
| モニタリング | 監査ログ、SIEM、異常検出 |
演習
-
セキュリティ アーキテクチャ: ヘルスケア アプリ (HIPAA) のセキュリティ アーキテクチャを設計します: 患者データ、医師ポータル、モバイル アプリ。対象: ネットワーク、認証、暗号化、監査。
-
脅威モデル: 電子商取引のチェックアウト フロー: ユーザー → カート → 支払い → 確認。 5つの脅威（STRIDEモデル）と各脅威に対する対策を列挙します。
-
ゼロトラスト移行: 同社は VPN ベースのアクセス (城と堀) を持っています。 500 人の開発者、50 のマイクロサービス。ゼロトラストへの移行計画を作成します。どのフェーズが先に来るでしょうか?