金融グレードのKubernetesプラットフォーム — 規制とクラウドネイティブの共存

• はじめに
• 金融業界のKubernetesの現実 — 規制環境の理解
  • 電子金融監督規定という出発点
  • 網分離とクラスタ分離アーキテクチャ
  • クラウド利用の規制フロー — 重要度評価と報告
• マルチテナンシー — ネームスペースで分けるか、クラスタで分けるか
  • 勘定系はどこまで載せるか
• セキュリティ強化スタック — ゲートはコードで
  • Pod Security Admissionという基本線
  • Kyvernoで実装する金融ポリシーゲート
  • 閉域網レジストリの運用
• 監査証跡 — すべての変更は記録され、承認される
  • API監査ログの長期保管
  • GitOpsと電子決裁の連動
• 可用性設計 — DRは等級で語る
  • RTO/RPO等級体系
  • 災害復旧訓練をプラットフォーム機能に
• 資格とアクセス統制 — 人が最大の変数
  • 人事システム連携
  • PIM(特権アクセス管理)パターン
• ネットワークポリシー — デフォルト拒否から始める
• 可観測性とコンプライアンス報告の自動化
• レガシー連携 — MCA/ESBとサービスメッシュの境界
• 導入ロードマップ — 情報系から対外系まで
• チェックリスト
• 落とし穴とアンチパターン
• おわりに
• 参考資料

はじめに

「Kubernetesを導入すればデプロイが速くなるんですよね?」金融機関のインフラ組織でこの言葉を聞くと、思わず苦笑してしまいます。技術的には正しいのですが、金融業界でKubernetesを導入するということは、単にクラスタを立ち上げる話ではないからです。電子金融監督規定、ネットワーク分離(網分離)要件、クラウド利用の報告手続き、監査証跡の義務、災害復旧訓練 — これらすべての規制要件をクラウドネイティブアーキテクチャの上で満たして初めて、「運用してよい」プラットフォームになります。

本記事は、金融環境でKubernetesプラットフォームを設計・運用してきた視点から、規制とクラウドネイティブが共存するアーキテクチャを整理したものです。一般企業のKubernetesベストプラクティスと何が違うのか、その差を技術でどう埋めるのかに焦点を当てます。

最初に明確にしておきます。本記事は技術ブログであり、法律助言や規制の有権解釈を提供するものではありません。実際の導入にあたっては、必ず所属機関のコンプライアンス・情報セキュリティ組織、必要に応じて監督当局の解釈を経てください。

金融業界のKubernetesの現実 — 規制環境の理解

電子金融監督規定という出発点

韓国の金融インフラ設計はすべて電子金融監督規定から始まります。この規定は、電子金融取引の安全性確保のために金融会社が守るべき人的・物的要件を定義しています。Kubernetesプラットフォームの観点で特に重要な条項のテーマは次のとおりです。

• 情報処理システムの内部網と外部網の分離(網分離)
• 電算資料の保護対策とアクセス統制
• 情報処理業務の委託(クラウド利用を含む)時の手続きと報告
• 災害復旧センターの構築と災害復旧訓練の実施
• 電算元帳(勘定系データ)の管理と変更統制

2023年以降、網分離規制は段階的に合理化される流れにあり、2024年に発表された金融分野網分離改善ロードマップにより、SaaS利用や生成AIの活用範囲が広がっています。しかし勘定系のような中核システムへの保守的な統制は依然として有効です。つまり「規制が緩んだから何でもできる」でも「何もできない」でもなく、システム等級ごとに異なる統制を適用する時代になったのです。

網分離とクラスタ分離アーキテクチャ

網分離要件をKubernetesに適用すると、最初にぶつかる問いが「クラスタをいくつに分けるか」です。一般的な金融機関の構成は次のとおりです。

                        [ インターネット ]
                            |
                   +--------+--------+
                   |  外部ファイアウォール |
                   +--------+--------+
                            |
  ..........................|.......................... DMZ区間
  :                +--------+--------+                :
  :                |  DMZクラスタ     |                :
  :                |  - チャネルGW    |                :
  :                |  - WAF/プロキシ  |                :
  :                |  - 対外系アダプタ |                :
  :                +--------+--------+                :
  ......................... | ..........................
                   +--------+--------+
                   | 内部FW/IPS      |   <- 一方向統制、許可ポート最小化
                   +--------+--------+
                            |
  ..........................|.......................... 内部網(業務網)
  :   +----------------+   |   +------------------+   :
  :   | 内部網クラスタ   +---+---+  情報系クラスタ    |  :
  :   | - チャネル系     |       |  - バッチ/分析    |  :
  :   | - 共通サービス   |       |  - データパイプライン| :
  :   +-------+--------+       +------------------+   :
  :           |                                       :
  :   +-------+--------+      +-------------------+   :
  :   | 勘定系(コアバンキング)|   |  運用/管理領域     |  :
  :   | 従来インフラまたは |      |  - CI/CD、レジストリ| :
  :   | 専用クラスタ      |      |  - 監視、ログ      |  :
  :   +----------------+      +-------------------+   :
  .....................................................

中核となる原則は次のとおりです。

1. DMZクラスタと内部網クラスタは物理的に分離します。1つのクラスタをネームスペースで分けてDMZと内部網を兼用する構成は、保守的な解釈では網分離の趣旨に反すると見なされます。
2. DMZから内部網への通信はファイアウォールで宛先・ポート単位のホワイトリストにします。KubernetesのNetworkPolicyは補助手段であり、ファイアウォールの代替ではありません。
3. 運用/管理領域(CI/CD、レジストリ、監視)は別領域に置き、各クラスタへのアクセスを一方向に設計します。レジストリからクラスタがイメージをpullする構造が基本です。
4. 開発網と本番網の分離も忘れてはいけません。開発者は開発網クラスタまでしか直接アクセスせず、本番反映はGitOpsパイプラインを通じてのみ行われます。

クラウド利用の規制フロー — 重要度評価と報告

パブリッククラウド上にKubernetes(EKS、AKS、GKEなどのマネージドサービスを含む)を載せるには、監督規定上のクラウドコンピューティングサービス利用手続きに従う必要があります。実務フローはおおよそ次のとおりです。

[1] 利用対象業務の識別
     |
[2] 重要度評価
     |  - 固有識別情報/個人信用情報の処理有無
     |  - 電子金融取引の安全性・信頼性への影響
     |
     +--> 重要業務でない --> [3a] 内部手続き + 利用状況管理
     |
     +--> 重要業務に該当 --> [3b] 業務継続計画 + 安全性確保措置
                              |
                          [4] 情報保護委員会の審議・議決
                              |
                          [5] 監督当局への事前報告(重要業務、利用7営業日前)
                              |
                          [6] 契約締結 + 利用開始
                              |
                          [7] 事後管理: 年1回以上の安全性点検、変更時の再評価

プラットフォームエンジニアにとって重要なのは、この手続きの成果物がプラットフォーム設計の入力値になるという点です。重要度評価で「重要業務」と分類されたワークロードは、より強い分離(専用クラスタまたは専用ノードプール)、より長い監査ログ保管、より高いDR等級を要求されます。評価結果をネームスペースのラベルとしてコード化しておけば、ポリシーエンジンが自動的に差等統制を適用できます。

apiVersion: v1
kind: Namespace
metadata:
  name: payment-core
  labels:
    bank.example.com/criticality: "critical"      # 重要度評価の結果
    bank.example.com/data-class: "pci-personal"   # データ等級
    bank.example.com/dr-tier: "tier-1"            # DR等級
    bank.example.com/owner-dept: "payments-dev"   # 所管部署

マルチテナンシー — ネームスペースで分けるか、クラスタで分けるか

Kubernetesマルチテナンシーの古典的な問いですが、金融では判断基準がより明確です。分離レベルを決めるのは技術的な好みではなく、データ等級と規制境界です。

勘定系はどこまで載せるか

最も熱いテーマです。勘定系(コアバンキング) — 元帳処理、与信・受信取引、日次バッチ(EOD) — をKubernetesに載せられるのか。2026年現在の現実的な答えは「周辺から、段階的に」です。

• 第1段階: 勘定系の照会系API。 元帳を直接更新しない残高照会、取引履歴照会APIをコンテナ化します。読み取り専用なので障害時の影響が限定的です。
• 第2段階: 勘定系周辺の補助サービス。 手数料計算、限度額検証、通知送信など、元帳トランザクションの前後処理を分離します。
• 第3段階: 新規商品の元帳分離。 新規デジタル商品の元帳を独立したマイクロ元帳として設計し、最初からクラウドネイティブで構築します。ネット専業銀行が検証してきた道筋です。
• 最後: 既存元帳の移行。 日次バッチの時間制約、トランザクション整合性、監督報告体系まですべて再検証が必要なため、数年単位のプログラムとして取り組みます。

ネームスペース分離を選んだ区間でも基本の骨格は必要です。ResourceQuotaとLimitRangeでリソース境界を、NetworkPolicyで通信境界を、RBACで権限境界を引きます。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: payment-core-quota
  namespace: payment-core
spec:
  hard:
    requests.cpu: "64"
    requests.memory: 256Gi
    limits.cpu: "96"
    pods: "300"
    services.loadbalancers: "0"   # LB作成はプラットフォームチームのみ

セキュリティ強化スタック — ゲートはコードで

金融のセキュリティ検査の特徴は「証跡」です。統制が存在する事実だけでなく、統制が動作した記録を提示しなければなりません。ポリシーをコードで管理すれば、両方が同時に解決します。

Pod Security Admissionという基本線

PodSecurityPolicyが削除されて久しいため、基本線はPod Security Admission(PSA)です。本番ネームスペースはrestrictedを既定で強制します。

apiVersion: v1
kind: Namespace
metadata:
  name: payment-core
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Kyvernoで実装する金融ポリシーゲート

PSAでカバーできない組織固有のポリシーはKyvernoで実装します。代表的な3つ — 閉域網レジストリの強制、イメージ署名検証、脆弱性スキャン合格の証明 — を1つの流れに束ねられます。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: financial-image-controls
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    # ルール1: 社内閉域網レジストリ以外のイメージを遮断
    - name: restrict-registry
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: "社内レジストリ(registry.bank.internal)のイメージのみ許可されます。"
        pattern:
          spec:
            containers:
              - image: "registry.bank.internal/*"
    # ルール2: latestタグ禁止 — 変更追跡が不可能
    - name: disallow-latest-tag
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: "イメージは不変タグ(digestまたはバージョン)を使用してください。"
        pattern:
          spec:
            containers:
              - image: "!*:latest"

イメージ署名検証はSigstore CosignとKyvernoのverifyImagesを組み合わせます。CIパイプラインがビルド後に署名し、クラスタの入口で署名を検証するため、「承認されたパイプラインを経ていないイメージは起動すらできない」という証跡が生まれます。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature
spec:
  validationFailureAction: Enforce
  webhookTimeoutSeconds: 30
  rules:
    - name: require-cosign-signature
      match:
        any:
          - resources:
              kinds: ["Pod"]
              namespaceSelector:
                matchLabels:
                  bank.example.com/criticality: critical
      verifyImages:
        - imageReferences:
            - "registry.bank.internal/*"
          attestors:
            - entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...
                      -----END PUBLIC KEY-----
          # 脆弱性スキャンattestationの検証: Critical脆弱性0件の証明
          attestations:
            - type: https://cosign.sigstore.dev/attestation/vuln/v1
              conditions:
                - all:
                    - key: "{{ scanner }}"
                      operator: Equals
                      value: "trivy"

閉域網レジストリの運用

インターネット遮断環境では、イメージのサプライチェーン自体を内製化する必要があります。

[ 外部インターネット区間(限定的許可) ]
   docker.io / ghcr.io / quay.io
        |
        v  (1) ミラーリング専用サーバーで定期同期
[ 検疫区間 ]
   ステージングレジストリ --> (2) Trivy/Grype全数スキャン
        |                    (3) ポリシー合格時に署名(cosign sign)
        v  (4) 承認イメージのみ内部搬入
[ 内部網 ]
   Harbor (registry.bank.internal)
        |- proxy-cacheプロジェクト: ベースイメージ
        |- appsプロジェクト: 社内ビルド成果物
        +- レプリケーション: DRサイトのレジストリ

Harborを使えばプロジェクト単位のRBAC、脆弱性スキャン連携、タグ不変性(immutability)、保持ポリシーを一度に解決でき、金融の閉域網標準構成として広く使われています。

監査証跡 — すべての変更は記録され、承認される

API監査ログの長期保管

Kubernetes APIサーバーのaudit logは「誰がいつ何を変更したか」の一次証跡です。監督規定の記録保存の趣旨に合わせ、通常1年以上、機関のポリシーによっては5年まで保管するよう設計します。

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # シークレットアクセスはメタデータレベルまですべて記録
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
  # ワークロード変更はリクエストボディまで記録
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "apps"
        resources: ["deployments", "statefulsets", "daemonsets"]
      - group: ""
        resources: ["pods", "services"]
  # 照会系リクエストは記録を最小化(ストレージコスト統制)
  - level: None
    verbs: ["get", "list", "watch"]
    users: ["system:kube-proxy", "system:apiserver"]
  - level: Metadata
    omitStages: ["RequestReceived"]

保管パイプラインは改ざん防止が核心です。audit logをノードローカルに置かず、Fluent Bitなどで即時に外部ログシステムへ転送した後、WORM(Write Once Read Many)属性のオブジェクトストレージへ日次でアーカイブします。ハッシュチェーンやストレージのオブジェクトロック機能で完全性を証明できるようにします。

GitOpsと電子決裁の連動

金融機関の変更管理は「決裁なくして反映なし」に要約されます。GitOpsはこの要件と意外に相性が良いのです。Gitが単一の真実の源泉であるため、決裁システムとGitマージを連動させれば変更統制が自動化されます。

開発者               Gitリポジトリ          電子決裁システム          ArgoCD
  |                      |                       |                  |
  |--- PR作成 ---------->|                       |                  |
  |                      |--- Webhook: 起案 ---->|                  |
  |                      |                       |--- 承認ライン --->|
  |                      |                       |   (リーダー/セキュリティ/|
  |                      |                       |    変更管理委員会) |
  |                      |<-- 承認コールバック ----|                  |
  |                      |  (マージロック解除)     |                  |
  |--- マージ ----------->|                       |                  |
  |                      |<------------------ 同期(ポーリング/Webhook)|
  |                      |                       |                  |
  |                      |  本番クラスタへ適用 + 適用結果を            |
  |                      |  決裁文書に自動添付(証跡回収)              |

実装ポイントは3つです。

1. 本番ブランチ保護ルール: 決裁承認状態を確認するstatus checkが通過しないとマージできないようにします。
2. 緊急変更(ブレークグラス)経路: 障害時の先対応・後決裁の経路を事前に定義し、使用時に自動で事後決裁の起案と通知が発生するようにします。
3. ドリフト検知: ArgoCDのselfHealとドリフト通知で「Gitにない変更」を即時検知します。これがそのまま不正変更検知統制の証跡になります。

可用性設計 — DRは等級で語る

RTO/RPO等級体系

金融のDRはシステムごとに一律ではなく、等級制で運用します。重要度評価の結果と連動した典型的な等級表は次のとおりです。

Kubernetes観点の実装はレイヤごとに分かれます。

• クラスタトポロジー: Tier 1・2はマルチAZノード分散が基本です。topologySpreadConstraintsとPodDisruptionBudgetで単一AZ障害をサービスが生き延びられるようにします。
• リージョン間DR: 主センターとDRセンター(または主リージョンとDRリージョン)にそれぞれ独立クラスタを置き、GitOpsで同一マニフェストを両方に適用します。「クラスタを復旧する」のではなく「どこでも同じ状態を再現する」モデルがクラウドネイティブDRの本質です。
• ステートフルデータ: 本当に難しいのはデータです。データベースはストレージ/DB層のレプリケーション機能に任せ、Kubernetesにはステートレスワークロード中心に載せるのが初期戦略として安全です。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: channel-api
spec:
  replicas: 6
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: channel-api
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: channel-api-pdb
spec:
  minAvailable: 4
  selector:
    matchLabels:
      app: channel-api

災害復旧訓練をプラットフォーム機能に

金融機関は定期的な災害復旧訓練(通常年1回以上、中核システムはより頻繁に)が義務です。これを手作業のイベントではなく、プラットフォームの反復可能な機能にすべきです。

• DNS/GSLB切替、DRクラスタのスケールアウト、データ整合性検証をスクリプト化し、訓練のたびに同一手順を実行します。
• 訓練結果(切替所要時間、データ損失量、失敗項目)を自動収集してレポートを生成します。このレポートが監督報告と内部監査の証跡になります。
• 平時にDRクラスタを情報系バッチや検証環境として活用すればコストを相殺できます。ただし、訓練時に即座に空けられるワークロードのみ配置します。

資格とアクセス統制 — 人が最大の変数

人事システム連携

金融の監査で定番の指摘事項が「退職者・異動者のアカウント未回収」です。Kubernetesのアクセス権限も例外ではないため、人事システムを権限の源泉とすべきです。

人事システム(HR) ---> IdP (Keycloak/AD) ---> OIDC ---> kube-apiserver
     |                    |                              |
     |  発令/退職イベント    |  グループメンバーシップ自動更新   |  RBACグループバインディング
     +------------------->|  (部署コード = IdPグループ)     |
                          +--- 未使用90日アカウント自動ロック  |

kubeconfigに静的トークンやクライアント証明書を配布する方式は回収不可能なので禁止し、必ずOIDCの短期トークンに統一します。RBACは個人ではなくIdPグループにバインドし、人事異動時に権限が自動で追従するようにします。

PIM(特権アクセス管理)パターン

本番クラスタの常時admin権限はゼロ名が原則です。必要なときに申請し、承認されたら時間制限付きの権限を受け取るJust-in-Timeパターンを適用します。

# 平時: 運用者は読み取り専用グループのみに所属
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ops-readonly
subjects:
  - kind: Group
    name: idp:platform-ops
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

[昇格フロー]
運用者 --> PIMポータルで理由 + 対象ネームスペース + 時間(最大4h)を申請
       --> 承認者(別人)が承認 --> 自動化が一時的なRoleBindingを作成
       --> 期限時刻にコントローラーがRoleBindingを自動削除
       --> 昇格区間のすべてのkubectlコマンドはaudit logで別途タグ付け・レビュー

セッション録画が必要な環境であれば、Teleportのようなアクセスプロキシを前段に置き、kubectl execセッションまで録画証跡を残します。

ネットワークポリシー — デフォルト拒否から始める

網分離がマクロな境界なら、クラスタ内部のミクロな境界はNetworkPolicyです。原則はシンプルです。デフォルト拒否(deny-all)を敷き、必要な通信のみホワイトリストにします。

# ステップ1: ネームスペースのデフォルト拒否 (Ingress + Egress)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: payment-core
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]
---
# ステップ2: DNSは許可 (egress遮断で最初に壊れるもの)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: payment-core
spec:
  podSelector: {}
  policyTypes: ["Egress"]
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

CNIの選択はCiliumとCalicoの二強です。CiliumはL7ポリシー(HTTPメソッド・パス単位の制御)とHubbleベースの通信可視化が強みで、「このPodは実際にどこと通信したのか」という監査の問いにフローログで答えられます。Calicoは成熟したポリシーモデルとBGP連携、エンタープライズ版のポリシー推薦機能が強みです。いずれにしても、ポリシー適用前にモニタリングモードでフローを収集して許可リストの草案を作り、その後に強制モードへ切り替える順序を推奨します。

勘定系方向のegressは特に狭く絞ります。CiliumならFQDNポリシーで特定のインターフェースドメインだけを開けられます。

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-core-banking-if
  namespace: channel-api
spec:
  endpointSelector:
    matchLabels:
      app: transfer-service
  egress:
    - toFQDNs:
        - matchName: "mca-gateway.core.bank.internal"
      toPorts:
        - ports:
            - port: "8443"
              protocol: TCP

可観測性とコンプライアンス報告の自動化

可観測性スタック(Prometheus、Loki、Tempo、Grafana)は一般企業と大きく変わりませんが、金融には2つの要求が追加されます。

1. 報告の自動化。 監督報告・内部点検に使う指標(可用率、障害件数、変更件数、脆弱性対応率)をダッシュボードではなく定期成果物として作る必要があります。Grafanaレポーティングやバッチジョブで月次PDF/CSVを生成し、決裁システムへ自動起案するレベルまで行けば運用負担が大きく減ります。
2. コンプライアンス常時点検。 CIS Kubernetes Benchmarkベースの点検(kube-bench)、ランタイム異常検知(Falco)、ポリシー違反状況(Kyverno PolicyReport)を定期実行し、結果を時系列で蓄積します。「点検は年1回の受検時だけ」ではなく「常時点検 + 受検時に履歴提出」の体系へ転換するのです。

[証跡パイプライン]
kube-bench (週1回) ---+
Falcoイベント (常時) --+--> ログパイプライン --> WORMストレージ (長期保管)
PolicyReport (常時) --+         |
audit log (常時) -----+         +--> 月次コンプライアンスレポートジョブ --> 電子決裁起案

レガシー連携 — MCA/ESBとサービスメッシュの境界

金融機関の内部にはすでにMCA(Multi Channel Architecture)やESB(Enterprise Service Bus)という統合レイヤがあります。Kubernetes上の新規サービスが勘定系と通信する経路は、このレガシー統合レイヤを迂回できない場合がほとんどです。

+---------------------------- 内部網クラスタ ----------------------------+
|                                                                       |
|  [チャネルサービスA] --\                                                |
|  [チャネルサービスB] ---+--> [メッシュegressゲートウェイ] ---+            |
|  [チャネルサービスC] --/      (mTLS終端、トラフィック統制)    |            |
|                                                          |            |
+----------------------------------------------------------|------------+
                                                           v
                                          [アダプタサービス (プロトコル変換)]
                                           REST/gRPC <-> 電文(固定長)
                                                           |
                                                    [MCA / ESB]
                                                           |
                                              +------------+-----------+
                                              | 勘定系(元帳/与信/受信)   |
                                              | 対外系(決済網/VAN網)    |
                                              +------------------------+

設計原則は次のとおりです。

• メッシュの境界はクラスタまで。 Istio/LinkerdのmTLSとトラフィックポリシーはクラスタ内部とegressゲートウェイまでに適用し、MCA/ESB区間は既存の電文セキュリティ体系(区間暗号化、電文完全性検証)を尊重します。メッシュをレガシーまで拡張する試みは大半が費用対効果に見合いません。
• アダプタサービスに変換を集中。 固定長電文、EBCDIC変換、電文ヘッダの取引コードマッピングのようなレガシー特殊性はアダプタ1か所に集めます。チャネルサービスが電文フォーマットを知ってしまうと、レガシーがクラスタ内に伝染します。
• タイムアウトとサーキットブレーカーは勘定系基準で。 勘定系電文応答のタイムアウト規約(例: 3秒応答、未応答時は取消電文)をメッシュの再試行ポリシーが壊さないよう設計します。無分別な自動再試行は二重取引事故に直結します。冪等キーと取消(補償)電文の設計を先に確認すべきです。

導入ロードマップ — 情報系から対外系まで

ビッグバン移行は金融では選択肢になりません。リスクの低い領域から段階的に拡張します。

各段階の終了条件を「ワークロード数」ではなく「証跡で立証可能な運用能力」として定義するのがコツです。例えば第1段階の終了条件は「情報系バッチ50本の移行」ではなく「障害訓練1回、DR切替1回、監査ログベースの変更追跡デモ1回の完了」であるべきです。

チェックリスト

導入・運用点検用のチェックリストです。

規制・ガバナンス

• クラウド利用の重要度評価を実施し、結果をネームスペースラベルとしてコード化したか
• 重要業務に該当する場合、情報保護委員会の議決と監督当局への事前報告を完了したか
• 変更管理(決裁)とGitOpsマージがシステム的に連動しているか
• ブレークグラス手順と事後決裁経路が定義されているか

アーキテクチャ

• DMZ/内部網クラスタが物理分離され、ファイアウォールのホワイトリストが最小化されているか
• データ等級・組織境界基準のクラスタ/ネームスペース分離基準文書があるか
• Tier別のRTO/RPOが定義され、マルチAZ分散とPDBが適用されているか
• 災害復旧訓練がスクリプト化され、反復実行可能か

セキュリティ

• すべての本番ネームスペースにPSA restrictedが強制されているか
• 閉域網レジストリ以外のイメージがポリシーで遮断されるか
• イメージ署名と脆弱性スキャン証明がadmissionで検証されるか
• NetworkPolicyのデフォルト拒否が全ネームスペースに適用されているか
• 本番クラスタの常時adminがゼロ名で、JIT昇格が動作するか

監査・可観測性

• audit logが改ざん防止ストレージにポリシー期間以上保管されているか
• 退職・異動時にクラスタアクセス権限が自動回収されるか
• コンプライアンス点検(kube-bench、ポリシーレポート)が常時実行され履歴が残るか
• 監督報告用の指標算出が自動化されているか

落とし穴とアンチパターン

• 「規制だからできません」の乱用。 実際の規定を確認すると、手続きを経れば可能な場合が多いのです。規定の原文と有権解釈を直接確認し、漠然とした慣行を規制と勘違いしないようにしましょう。
• ネームスペース万能主義。 網区間が異なるワークロードを1つのクラスタに詰め込むと、受検時にアーキテクチャ全体を描き直すことになります。
• ポリシーゲートなしでワークロード先行。 移行を始めた後にポリシーを差し込むと、既存ワークロードが大量に違反状態になり、強制モードへの切替が不可能になります。ゲートが先です。
• audit logをノードに放置。 ノード障害や侵害時に証跡が一緒に消えます。リアルタイム外部転送が基本です。
• DRを文書だけで保有。 訓練で一度も切り替えたことのないDRは、無いのと同じです。訓練の自動化に投資すべきです。
• メッシュでレガシーまで覆おうとする試み。 MCA/ESB区間は既存統制を尊重し、アダプタで境界を引くのが現実的です。
• 再試行ポリシーの放置。 メッシュ・クライアントの自動再試行が勘定系の冪等性設計と衝突すると、二重振込事故が起きます。金融システムで最も高くつくバグです。

おわりに

金融グレードKubernetesプラットフォームの本質は「規制要件をコードに翻訳する作業」です。網分離はクラスタトポロジーへ、変更統制はGitOpsと決裁連動へ、アクセス統制は人事連携OIDCとJIT昇格へ、監査対応はWORM証跡パイプラインへと翻訳されます。この翻訳がうまくできた組織では、規制はもはやスピードの敵ではなく、自動化されたガードレールの中でむしろ速く動ける基盤になります。

規制とクラウドネイティブは共存できます。ただし、その共存は自然には訪れず、プラットフォームチームが規定文書とYAMLを同時に読めるようになって初めて可能になるのです。

参考資料

• Kubernetes公式ドキュメント — Pod Security Admission
• Kubernetes公式ドキュメント — Auditing
• Kubernetes公式ドキュメント — Network Policies
• Kyverno公式ドキュメント
• Sigstore Cosign公式ドキュメント
• Cilium公式ドキュメント — Network Policy
• Calico公式ドキュメント
• Harbor公式ドキュメント
• Argo CD公式ドキュメント
• CIS Kubernetes Benchmark
• 韓国法令情報センター — 電子金融監督規定
• 金融監督院
• BIS — Principles for Operational Resilience