会社情報
採用情報
お問い合わせ
Article

サイバーセキュリティ最新トピック：ゼロトラストから量子暗号まで

高田晃太郎
サイバーセキュリティ最新トピック：ゼロトラストから量子暗号まで

IBMの2024年データ漏えい調査では、平均被害額は約4.88百万米ドルに達し¹、特定から封じ込めまでの平均期間は約292日と報告されています²。また、Verizonの2024 DBIRは侵害の68%に人的要素が関与すると示し³、境界防御中心の設計だけでは崩れることを裏付けました。複数の公開レポートを突き合わせると、攻撃はAPI・ID・サプライチェーンへと重心を移し⁴、検知よりも予防と封じ込めの設計が投資対効果を左右する局面に入っています。抽象的な理念ではなく、業務運用に乗るゼロトラストアーキテクチャ（ZTA）の作法と、量子計算時代に備えるポスト量子暗号（PQC）への移行実務を同時に進めることが、2025年の技術ロードマップで競争優位を生む最短ルートです。

ゼロトラストの現実解：境界からアイデンティティへ

ゼロトラストを「全て疑う」というスローガンで止めると、現場は前に進みません。実務では、アイデンティティ（ユーザーやワークロードの固有性）を信頼の起点に据え、コンテキスト（ユーザー、デバイス、場所、時間、リスクスコア）に基づくきめ細かな許可を、ネットワークとアプリの両層で一貫して強制する設計に落とし込みます⁵。研究データでは、ネットワーク境界の強化単独よりも、認証・認可の厳格化とマイクロセグメンテーションの併用が横移動を抑制するとされます¹⁴。例えば、一般的なSaaSの刷新ではフルトンネルVPNを段階的にZTNA（Zero Trust Network Access）へ置換し、ユーザーごとのアプリ単位アクセスと端末姿勢チェック（デバイスのセキュリティ準拠状況の確認）を統合します。これにより、ヘルプデスクのVPN関連チケットが減少しやすくなり、CIAM（顧客ID/アクセス管理）への不正試行もMFA強化で検知から抑止へとシフトしやすくなります。

データが示す攻撃の変化と設計方針

侵入の初手がフィッシングや資格情報詐取である確率が高い以上³、認証段階の強化が費用対効果に直結します。具体的には、フィッシング耐性のMFA（パスキーなど）⁶、デバイス姿勢の連携、mTLS（双方向TLS）の徹底、アプリケーション層のコンテキスト認可を一貫させることで、侵害時の横展開を構造的に困難化します。ネットワークは許可の補助線であり、L3/L4の閉域だけでは足りません。アプリ側での意図的な拒否、すなわちポリシー・アズ・コードの導入が要です。

ポリシーをコード化する：OPA/Regoの例

ゼロトラストの「許可の条件」を自然言語で運用するとドリフトが起きます。OPA（Open Policy Agent）/Regoで認可をコード化し、CIでレビューしながら段階導入するのが実装しやすい手筋です。以下は、WebAuthnで認証済みかつMDM準拠端末からの閲覧のみを許可する最小例です。

package authz

default allow = false

allow {
  input.user.authn == "webauthn"
  input.device.mdm_compliant == true
  input.tls.client_cert_present == true
  input.request.method == "GET"
  input.request.resource == "invoices"
  input.user.claims.role == "finance"
}

deny[msg] {
  not allow
  msg := "policy: posture or role not satisfied"
}

アプリケーションはリバースプロキシやサイドカーから得たTLS・端末・認証のコンテキストを入力として渡し、許可はアプリ側で最終決定します。この分離が、実装の一貫性と監査可能性を両立させます。

ネットワークとサービスの強制力：Kubernetes/Istio例

ネットワーク層では、デフォルト拒否と必要最小限の許可に徹します。KubernetesのNetworkPolicyで入口と出口を明示的に限定し、L7はサービスメッシュ（例：Istio）でmTLSと属性ベース許可を強制する構成が実務では扱いやすい選択です。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-except-proxy
  namespace: apps
spec:
  podSelector: {}
  policyTypes: ["Ingress","Egress"]
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: envoy-proxy
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: core

サービスメッシュの認可は、アイデンティティ（SPIFFE ID：ワークロードのID）とJWT（認証トークン）のクレームに紐づく条件で明確に定義します。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: finance-readonly
  namespace: apps
spec:
  selector:
    matchLabels:
      app: billing
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["spiffe://corp/workload/frontend"]
        requestPrincipals: ["*"]
    to:
    - operation:
        methods: ["GET"]
        paths: ["/v1/invoices/*"]
    when:
    - key: request.auth.claims[role]
      values: ["finance"]

これにより、トラフィック経路の許容とアプリの意図の整合性を担保し、設定の片側変更による抜け道を減らします。

フィッシング耐性MFAとパスキー：突破口を塞ぐ

人的要素が大勢を占める以上、最初の突破口である資格情報を物理的に奪いにくくするのが合理的です。FIDO2/WebAuthnによるパスキー（公開鍵暗号にもとづくフィッシング耐性の認証情報）は、チャレンジレスポンスとオリジン束縛により、一般的なフィッシングや中間者攻撃に対して構造的に耐性を持ちます⁶。企業アカウントへの適用は待ったなしです。導入の現場では、既存IdPのMFA設定でパスキーを有効化するだけでなく、カスタムアプリが発行するセッションの再認証や高リスク操作のステップアップにWebAuthnを直接組み込み、認可の文脈と連動させるのが効果的です。

WebAuthn実装の最小例（Node.js）

実装は専用ライブラリで大幅に簡素化できます。以下は登録と検証の最小パスです。

import express from 'express';
import session from 'express-session';
import { generateRegistrationOptions, verifyRegistrationResponse } from '@simplewebauthn/server';

const app = express();
app.use(express.json());
app.use(session({ secret: 'change-me', resave: false, saveUninitialized: true }));

const rpID = 'example.com';
const rpName = 'Example Corp';
const userDB = new Map();

app.post('/webauthn/register/options', (req, res) => {
  const { userId, username } = req.body;
  const opts = generateRegistrationOptions({
    rpID,
    rpName,
    userID: String(userId),
    userName: username,
    attestationType: 'none',
    authenticatorSelection: { residentKey: 'preferred', userVerification: 'required' },
  });
  req.session.challenge = opts.challenge;
  res.json(opts);
});

app.post('/webauthn/register/verify', async (req, res) => {
  const body = req.body;
  const expectedChallenge = req.session.challenge;
  const { verified, registrationInfo } = await verifyRegistrationResponse({
    response: body,
    expectedChallenge,
    expectedOrigin: `https://${rpID}`,
    expectedRPID: rpID,
  });
  if (!verified) return res.status(400).json({ error: 'verification failed' });
  const { credentialPublicKey, credentialID, counter } = registrationInfo;
  userDB.set(body.response.clientDataJSON?.userHandle || 'u', { credentialID, credentialPublicKey, counter });
  res.json({ ok: true });
});

app.listen(3000);

業務に統合する際は、成功した認証事実をIdPのトークンに反映させ、デバイス姿勢や地理情報と合わせて認可ポリシーの属性として消費します。これにより、単なるログイン強化にとどまらず、リスクベースのアクセス制御へと拡張できます。

量子時代に備える：PQCと量子暗号の正しい使い分け

「量子暗号」という語はしばしば混同を生みます。実務でまず検討すべきは、量子計算機に対して耐性を持つ古典的アルゴリズム、すなわちポスト量子暗号（PQC）です。NISTは選定を進め、格子ベースのCRYSTALS-Kyber（鍵共有）とCRYSTALS-Dilithium（署名）、ハッシュベースのSPHINCS+（署名）を標準化段階に進めています⁷。米国政府は移行方針（CNSA 2.0、OMBメモ）を示し、2030年代前半を見据えた段階的置換を求めています⁸。対して量子鍵配送（QKD）は物理層で鍵を配送する技術ですが、専用インフラが必要で広域・多拠点・クラウド接続の現実には馴染みにくい⁹。企業システムの主戦場はTLS、VPN、アプリ署名、コード署名であり、PQCによる暗号アジリティ（アルゴリズムの置換容易性）の確保が最優先となります。

PQC移行の現実的な手順と測る指標

まず、組織内の暗号使用実態をインベントリ化（棚卸し）します。TLS終端、mTLS、VPN、データベース接続、アプリ内の署名、PKI、HSM、モバイルアプリのピン留め、IoTファームウェアの検証まで、経路と保護対象を洗い出します。次に、ハイブリッド鍵共有（例：X25519とKyberの併用）をテストベッドで評価し、レイテンシとCPU負荷を計測します。大手の検証では、Kyber512の鍵共有でハンドシェイク時間の増加は小さく、帯域への影響は限定的という結果が報告されています¹⁰。重要なのは、証明書署名アルゴリズムの置換はエコシステム影響が大きいため、まず鍵共有のハイブリッド化から着手し、署名はサブシステム単位でパイロットする順序です。

ハイブリッドTLSの最小検証（OpenSSL + OQS）

テスト環境では、OpenSSL 3系にOQSプロバイダを組み合わせ、ハイブリッド鍵共有グループを指定するだけで往復の可否を確認できます¹¹。

# サーバ（oqsproviderをロードし、ハイブリッドグループを指定）
openssl s_server -key server.key -cert server.crt -accept 8443 \
  -tls1_3 -provider oqsprovider -provider default \
  -groups x25519_kyber512

# クライアント（同様にoqsproviderをロード）
openssl s_client -connect localhost:8443 \
  -tls1_3 -provider oqsprovider -provider default \
  -groups x25519_kyber512

本番導入では、負荷分散機やゲートウェイのベンダー対応状況、相互接続先の準備度合い、観測指標（ハンドシェイクP95、CPUサイクル、再試行率）をモニタリングに組み込み、フェーズドリリースで安全に広げます。

QKDの適用可能性と経営判断

QKDは物理層で鍵配送を保護しますが、地理的制約、装置コスト、リダンダンシー構成の複雑さが伴います⁹。金融の拠点間でレイテンシ要件が厳格なケースなど、用途は限定的です。クラウド・SaaS・モバイル・エッジが主戦となる多くの企業にとって、投資の優先順位はPQC対応と暗号アジリティの確保に置くのが合理的です。

サプライチェーンと復旧力：署名、SBOM、バックアップ

ゼロトラストとPQCを進めても、供給経路が汚染されればリスクは残ります。ソフトウェアの完全性を検証可能にするサプライチェーン対策は、署名の全面適用、SBOM（Software Bill of Materials：ソフトウェア部品表）の配布と検証、ビルド台の隔離と再現性の確保が柱です。Sigstore/cosignによるコンテナ署名は導入容易性が高く、Kubernetesの入場管理と組み合わせるとデプロイ前の検証を自動化できます¹²。

ポリシーで署名を強制する：実装の断片

Admission Webhookやポリシーエンジンで、未署名アーティファクトのデプロイを拒否します。以下はOpen Policy Agent Gatekeeperでの概念表現に近いRego断片です。

package k8srequiredsign

deny[msg] {
  input.review.kind.kind == "Pod"
  some i
  img := input.review.object.spec.containers[i].image
  not is_signed(img)
  msg := sprintf("image %s is not signed by trusted issuer", [img])
}

is_signed(img) {
  # 概念例：検証結果がアノテーションで伝搬される前提
  input.review.object.metadata.annotations[concat("/", ["cosign.sigstore.dev", img])] == "verified"
}

実際にはcosignの検証をAdmission側で行い、結果を明示的なステータスとして扱います。パイプラインの各段で同じ鍵階層とポリシーを共有すると、バイパス経路が減ります。

バックアップは最後の防波堤：復旧時間を事前に測る

ランサムウェアは暗号化だけでなくバックアップの改ざんも狙います。オブジェクトロックやWORM、スナップショットのイミュータビリティを有効化し、論理削除や権限昇格の監査イベントにトリガーを張り、隔離保管の検証復元を定期実施します¹³。RTOとRPOはダッシュボードで可視化し、四半期ごとに実測更新します。単なる方針文書ではなく、復旧に要する作業手順を自動化しておくことが、インシデント対応の心理的負担を下げます。

実装とROI：小さく始めて大きく外さない

経営インパクトの観点では、最初の四半期で測れる効果にフォーカスします。フィッシング耐性MFAの適用率、VPN関連チケット数、ハンドシェイクのレイテンシ、未署名イメージのブロック率、復旧演習の達成時間など、部門横断の合意を取りやすい指標を選びます。多くの組織では、MFA切替の初期波でヘルプデスクの一時的な負荷増が発生しやすいため、セルフサービスポータルと分散展開を組み合わせてピークを平準化する計画が有効です。ITとセキュリティ、HR、法務の連携を早期に設け、ポリシー変更と教育・通達を同時進行させると、ユーザー体験の毀損なく移行が進みます。

Envoyでの外部認可連携：ゼロトラストの接着剤

プロキシ層で一貫したポリシー適用を行うと、アプリ改修の波及を抑えられます。Envoyのext_authzでOPAなどの外部エンジンと連携する設定の断片は次の通りです¹⁵。

static_resources:
  listeners:
  - name: public
    address:
      socket_address: { address: 0.0.0.0, port_value: 8080 }
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          route_config: { name: local_route, virtual_hosts: [ { name: app, domains: ["*"], routes: [ { match: { prefix: "/" }, route: { cluster: app } } ] } ] }
          http_filters:
          - name: envoy.filters.http.ext_authz
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz
              http_service:
                server_uri:
                  uri: http://opa:8181
                  cluster: opa
                  timeout: 0.25s
                authorization_request: { headers_to_add: [ { key: x-device-posture, value: "%REQ(X-DEVICE-POSTURE)%" } ] }
          - name: envoy.filters.http.router
  clusters:
  - name: app
    connect_timeout: 0.5s
    load_assignment: { cluster_name: app, endpoints: [ { lb_endpoints: [ { endpoint: { address: { socket_address: { address: app, port_value: 3000 } } } } ] } ] }
  - name: opa
    connect_timeout: 0.25s
    load_assignment: { cluster_name: opa, endpoints: [ { lb_endpoints: [ { endpoint: { address: { socket_address: { address: opa, port_value: 8181 } } } } ] } ] }

プロキシが収集するテレメトリは、リスクスコア算出と検知の起点としても有用です。検知・対応（EDR/NDR）と許可の設計がデータで接続されることで、意思決定サイクルが短縮されます。

コード署名とアプリ検証：PQC時代を見据えた実験

アプリやファームウェアの署名は、PQCへの置換影響が大きい領域です。現時点では本番の署名アルゴリズムを拙速に切り替えるのではなく、並行してPQC署名の検証パスを実装し、メトリクスと互換性の問題点を記録するアプローチが現実的です。将来の切替時にソフトランディングできます。

mTLSの徹底と可視化

社内トラフィックの暗号化は、ゼロトラストの基礎体力です。証明書の自動発行とローテーション、鍵の保護、ジャストインタイム発行を整え、証明書の存否と属性をポリシーに取り込めるようにしておくと、運用の負債が減ります。サービスメッシュやL4プロキシの選定は、証明書のライフサイクル管理の容易さを主要基準にするとよいでしょう¹⁴。

まとめ：今四半期に着手し、来期に拡張する

全方位に一斉着手するよりも、突破口の塞ぎ込みと暗号の将来備えに集中する方が投資対効果は高まります。まず、パスキーによるフィッシング耐性MFAを主要アカウントへ適用し⁶、コンテキスト認可とプロキシ連携で許可の一貫性を確立します。次に、PQCのハイブリッド鍵共有をテストベッドで検証し⁷¹¹、TLS終端の一部から段階導入します。並行して、署名の強制とSBOMの検証をCI/CDに織り込み、未署名の流入を組織的に拒否できる体制を整えます¹²。最後に、復旧演習で実測のRTO/RPOを更新し、バックアップのイミュータビリティを確認します¹³。技術と運用の両輪が回り始めたとき、ゼロトラストは理念から製品的な習慣へと変わります。あなたの組織では、今四半期にどの指標を更新しますか。MFAの適用率、ハンドシェイクのP95、未署名ブロック率、復旧演習の達成時間、そのどれからでも前進は測れます。次のアクションとして、パイロット対象のシステムを一つ選び、測定指標と責任者を決め、四週間のスプリントで小さな成功体験を積み上げてください。そこから拡張すれば十分に間に合います。

参考文献

  1. IBM Security. Escalating Data Breach Disruption Pushes Costs to New Highs (2024 press release). https://newsroom.ibm.com/2024-07-30-ibm-report-escalating-data-breach-disruption-pushes-costs-to-new-highs
  2. IBM SecurityIntelligence. What’s New in the 2024 Cost of a Data Breach Report. https://securityintelligence.com/posts/whats-new-2024-cost-of-a-data-breach-report/
  3. Help Net Security. Verizon 2024 Data Breach Investigations Report (DBIR): 68% of breaches involve the human element. https://www.helpnetsecurity.com/2024/05/02/verizon-2024-data-breach-investigations-report-dbir/
  4. Security Magazine. Verizon 2024 DBIR shows the risk of the human element and rise of API threats. https://www.securitymagazine.com/articles/100629-verizon-2024-data-breach-report-shows-the-risk-of-the-human-element
  5. NIST SP 800-207. Zero Trust Architecture. https://csrc.nist.gov/publications/detail/sp/800-207/final
  6. CISA. Phishing-Resistant MFA: The Key to Peace of Mind. https://www.cisa.gov/news-events/news/phishing-resistant-mfa-key-peace-mind
  7. NIST. Post-Quantum Cryptography Project (FIPS 203/204/205, Aug 13, 2024). https://csrc.nist.gov/projects/post-quantum-cryptography
  8. The White House OSTP. Fact Sheet: Securing a Post-Quantum Cryptography Future (2024-08-13). https://www.whitehouse.gov/ostp/news-updates/2024/08/13/fact-sheet-biden-harris-administration-continues-work-to-secure-a-post-quantum-cryptography-future/
  9. EPJ Quantum Technology. Policy perspectives on ‘post-quantum cryptography’ vs ‘quantum cryptography’. https://epjquantumtechnology.springeropen.com/articles/10.1140/epjqt/s40507-025-00350-5
  10. Cloudflare Blog. Kyber is ready for the Internet (post-quantum key agreement performance). https://blog.cloudflare.com/kyber-is-ready-for-the-internet/
  11. Open Quantum Safe. oqs-provider for OpenSSL 3. https://github.com/open-quantum-safe/oqs-provider
  12. Sigstore Docs. Cosign overview. https://docs.sigstore.dev/cosign/overview/
  13. CISA. Stop Ransomware Guide. https://www.cisa.gov/stopransomware/guide
  14. CISA. Zero Trust Maturity Model 2.0. https://www.cisa.gov/zero-trust-maturity-model
  15. Envoy Proxy Docs. External Authorization (ext_authz) filter. https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/ext_authz_filter