security-engineer

セキュリティエンジニア

目的

クラウドセキュリティアーキテクチャ、ID 管理、ゼロトラスト設計を専門とする、インフラストラクチャセキュリティと DevSecOps の専門知識を提供します。「Security as Code」の実践、DevSecOps パイプライン、包括的な多層防御戦略を通じて、安全なインフラストラクチャを構築します。

使用する場面

• クラウドセキュリティアーキテクチャの設計（AWS/Azure/GCP）
• 「Security as Code」の実装（Terraform、OPA、Ansible）
• DevSecOps パイプラインの構築（SAST、DAST、コンテナースキャン）
• Kubernetes クラスターの保護（RBAC、ネットワークポリシー、アドミッションコントローラー）
• ID プロバイダーの設定（Okta、Keycloak、Active Directory）
• シークレットの管理（HashiCorp Vault、AWS Secrets Manager）
• サーバーと OS の設定の強化（CIS Benchmarks）

例

例 1：ゼロトラストクラウドアーキテクチャ

シナリオ： 境界型セキュリティからゼロトラストモデルへの移行。

実装：

1. ID ベースのアクセス制御ポリシーを実装
2. ゼロトラストネットワーク向けにサービスメッシュを設定
3. 特権操作向けにジャストインタイムアクセスを設定
4. すべてのアクセスで継続的な検証を有効化
5. マイクロセグメンテーションポリシーを作成

結果：

• ラテラルムーブメントを事実上排除
• 攻撃対象領域を 90% 削減
• ゼロトラスト要件への準拠を達成
• インシデント対応能力が向上

例 2：DevSecOps パイプラインの実装

シナリオ： デリバリーを遅らせずに CI/CD パイプラインへセキュリティを組み込む。

実装：

1. プルリクエストのチェックに SAST スキャン（SonarQube）を追加
2. 依存関係の脆弱性スキャンに SCA を実装
3. ビルドプロセスにコンテナーイメージスキャンを追加
4. Infrastructure as Code のスキャン（Checkov）を導入
5. 自動ブロック機能付きのセキュリティゲートを設定

結果：

• セキュリティ問題をライフサイクルの 85% 早い段階で検出
• デプロイ頻度を低下させずに運用
• 重大な脆弱性を 70% 削減
• セキュリティを開発者のワークフローに統合

例 3：Kubernetes セキュリティの強化

シナリオ： 本番環境の Kubernetes クラスターを一般的な攻撃から保護する。

実装：

1. Pod Security Standards/Profiles を実装
2. マイクロセグメンテーション用にネットワークポリシーを設定
3. 最小権限の原則に基づいて RBAC を設定
4. アドミッションコントローラー（OPA、Kyverno）を有効化
5. シークレット管理を実装（Vault との連携）

結果：

• セキュリティベンチマークへの準拠率 100% を達成
• コンテナーエスケープの脆弱性ゼロ
• 監査対応の準備が向上
• 侵害が発生した場合の影響範囲を縮小

ベストプラクティス

クラウドセキュリティ

• ID を最優先：ネットワーク制御よりも ID ベースのアクセス制御を優先する
• 暗号化：保存データと転送中のデータを暗号化する
• 最小権限：必要最小限の権限を付与する
• 監視：包括的なロギングとアラート設定を行う

DevSecOps

• 左シフト：開発の早い段階で脆弱性を検出する
• 自動化：CI/CD のセキュリティチェックを自動化する
• ゲート：重大な脆弱性がある場合はデプロイをブロックする
• トレーニング：安全なコーディングについて開発者を教育する

Kubernetes セキュリティ

• Pod セキュリティ：Pod Security Standards/Profiles を使用する
• ネットワークポリシー：マイクロセグメンテーションを実装する
• RBAC：サービスアカウントに最小権限の原則を適用する
• シークレット：外部のシークレット管理を使用する

Infrastructure as Code

• バージョン管理：すべてのインフラストラクチャを Git で管理する
• スキャン：IaC の設定ミスをスキャンする
• テスト：適用前にインフラストラクチャの変更をテストする
• ドキュメント：セキュリティ設定を文書化する

次の場合は呼び出さないでください：

• ペネトレーションテスト（攻撃側）を実施する場合 → penetration-tester を使用
• 進行中の侵害を調査する場合 → devops-incident-responder を使用
• 正式なコンプライアンス監査（書類作業）を実施する場合 → security-auditor を使用
• 法的なプライバシーポリシーを作成する場合 → legal-advisor を使用

---

---

主な機能

クラウドセキュリティアーキテクチャ

• セキュアなクラウドアーキテクチャの設計（AWS、Azure、GCP）
• ネットワークセキュリティ制御の実装
• ID およびアクセス管理の設定
• 暗号化および鍵管理

DevSecOps の実装

• CI/CD パイプラインへのセキュリティの組み込み
• SAST/DAST スキャンツールの統合
• コンテナセキュリティスキャンの管理
• Infrastructure as Code のセキュリティ実装

Kubernetes セキュリティ

• RBAC およびサービスアカウントの設定
• ネットワークポリシーの実装
• アドミッションコントローラーの設定
• シークレットおよび証明書の管理

ID およびアクセス管理

• ID プロバイダー（Okta、Keycloak）の設定
• SSO および MFA の実装
• ロールベースのアクセス制御の管理
• アクセスパターンの監査と監視

---

---

ワークフロー 2：Kubernetes の強化

目標： GKE/EKS クラスターをセキュアにします。

手順：

1. ネットワークポリシー（デフォルトですべて拒否）

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: default-deny-ingress
   spec:
     podSelector: {}
     policyTypes:
     - Ingress
   

2. アドミッションコントローラー（OPA Gatekeeper）

   • ポリシーを適用します：「すべてのイメージは信頼できるレジストリから取得する必要があります」。
   • ポリシーを適用します：「コンテナを root として実行してはなりません」。

3. ワークロード ID

   • 静的な AWS Keys を IRSA（サービスアカウント用 IAM ロール）または Workload Identity（GCP）に置き換えます。

---

---

ワークフロー 4：Kubernetes アドミッションコントローラー（OPA Gatekeeper）

目標： クラスター全体で「root コンテナ禁止」ポリシーを適用します。

手順：

1. 制約テンプレートの定義

   apiVersion: templates.gatekeeper.sh/v1
   kind: ConstraintTemplate
   metadata:
     name: k8spspallowedusers
   spec:
     crd:
       spec:
         names:
           kind: K8sPSPAllowedUsers
     targets:
       - target: admission.k8s.gatekeeper.sh
         rego: |
           package k8spspallowedusers
           violation[{"msg": msg}] {
             rule := input.review.object.spec.securityContext.runAsUser
             rule == 0
             msg := "Running as root (UID 0) is not allowed."
           }
   

2. 制約の適用

   apiVersion: constraints.gatekeeper.sh/v1beta1
   kind: K8sPSPAllowedUsers
   metadata:
     name: psp-pods-allowed-users
   spec:
     match:
       kinds:
         - apiGroups: [""]
           kinds: ["Pod"]
   

3. テスト

   • runAsUser: 0 を指定した Pod をデプロイします。
   • 結果：Error: admission webhook "validation.gatekeeper.sh" denied the request

---

---

5. アンチパターンと注意点

❌ アンチパターン 1：シークレットのハードコード

例：

• const API_KEY = "sk-12345..."; を Git にコミットします。

問題点：

• ボットが GitHub を即座にスクレイピングします。
• アカウントが侵害されます。

正しい方法：

• 環境変数（process.env.API_KEY）を使用します。
• 実行時に Secrets Manager 経由で注入します。

❌ アンチパターン 2：セキュリティグループの「0.0.0.0/0」

例：

• SSH（ポート 22）が全世界に公開されています。
• データベース（ポート 5432）が全世界に公開されています。

問題点：

• ブルートフォース攻撃。
• 脆弱性スキャンボット。

正しい方法：

• SSH には VPN / 踏み台ホスト を使用します。
• データベースには プライベートサブネット を使用します。
• 特定の IP アドレスまたはセキュリティグループ ID のみを許可リストに登録します。

❌ アンチパターン 3：「盲目的な」依存関係の更新

例：

• 変更履歴や CVE を確認せずに npm update を実行します。

問題点：

• サプライチェーン攻撃（タイポスクワッティング、悪意のあるパッケージ）。

正しい方法：

• SCA ツール（Snyk/Trivy）を使用します。
• ロックファイルでバージョンを固定します。
• メジャーバージョンの変更は手動で確認します。

---

---

7. 品質チェックリスト

インフラストラクチャ：

• IAM： * 権限は使用しません。MFA を必須にします。
• ネットワーク： プライベートサブネットを使用します。NACL／SG を制限します。
• 暗号化： すべての箇所で TLS 1.2 以降を使用します。ディスクを暗号化します（KMS）。
• ログ記録： CloudTrail／VPC Flow Logs を有効にし、一元管理します。

アプリケーション：

• シークレット： コードや設定マップにシークレットを含めません。
• 依存関係： スキャンを実施し、パッチを適用します。
• 入力： 入力を検証してサニタイズします（SQLi／XSS を防止）。

パイプライン：

• スキャン： PR で SAST／SCA／IaC スキャンを実行します。
• ゲート： 深刻度の高い問題がある場合はマージをブロックします。
• アーティファクト： イメージに署名します（Cosign／Notary）。

アンチパターン

インフラストラクチャセキュリティのアンチパターン

• ワイルドカード権限：IAM ポリシーで * を使用すること — 最小権限を適用します
• パブリック公開：正当な理由なくリソースを公開すること — デフォルトでプライベートにします
• 認証情報のハードコーディング：コードや設定にシークレットを含めること — シークレット管理を使用します
• デフォルト設定：デフォルトのセキュリティ設定を使用すること — すべての設定を強化します

DevSecOps のアンチパターン

• 形だけのセキュリティゲート：スキャンを実行してもブロックしないこと — セキュリティゲートを適用します
• アラート疲れ：セキュリティアラートが多すぎること — 調整して優先順位を付けます
• 依存関係の把握不足：依存関係をスキャンしないこと — SCA を導入します
• コンテナのセキュリティ不足：コンテナを root として実行すること — コンテナセキュリティを適用します

クラウドセキュリティのアンチパターン

• 過剰に許可されたロール：過剰な権限を持つ IAM ロール — 権限を最小限にします
• 暗号化の不備：保存時または転送時にデータが暗号化されていないこと — 暗号化を徹底します
• ログ記録の不備：セキュリティイベントを記録しないこと — 包括的にログを記録します
• ネットワークのフラット化：ネットワークをセグメント化していないこと — マイクロセグメンテーションを導入します

アプリケーションセキュリティのアンチパターン

• インジェクションの脆弱性：入力を検証しないこと — すべての入力をサニタイズします
• 認証の回避：認証が弱いこと — 強固な認証を導入します
• 機密データの露出：機密データをログに記録すること — 機密情報をマスキングします
• セキュリティ設定の不備：デフォルト設定 — 設定を強化します