エグゼクティブ・サマリー
現代のエンタープライズは、クラウド基盤の上に成り立っています。Software as a Service（SaaS）およびInfrastructure as a Service（IaaS）プラットフォームの急速な導入により、ビジネスの俊敏性が加速し、設備投資が最小限に抑えられ、かつてないほどの事業運営のスケールが実現しました。
しかし、クラウドホスト型システムに全面的に依存することで、重大なパラドックスが生じています。つまり、組織はコアインフラストラクチャを物理的・管理的な境界の外に移行させることで、外部ネットワークやサードパーティプロバイダーに対する深刻かつシステム全体にわたる依存関係を生み出してしまったのです。
物理的なファイバーの切断、ルーティングの構成ミス、ドメインネームシステム（DNS）の障害、主要なハイパースケーラーの地域的なサービス停止などによってこれらの依存関係に障害が発生すると、現代の業務は即座に停止してしまいます。ヘルスケア、防衛、製造、公益事業、金融、小売、運輸などの基幹産業にとって、クラウド接続の喪失は単なるIT上の不便さにとどまらず、人々の安全、国家の安全保障、経済の安定を脅かす脅威となります。
クラウドファーストの時代におけるビジネス継続性計画（BCP）には、追加の計画が必要です。従来のBCP手法を検討し、AWS Outpostsのような最新のEdgeコンピューティングフレームワークを掘り下げ、Okta Local Authentication Serviceのオフライン機能を通じてアイデンティティ中心のサバイバビリティを実証することで、ローカライズされたサバイバビリティがもはや贅沢品ではないことを示します。これは、現代のエンタープライズにとって基本的な戦略です。
クラウドはビジネス継続性計画をどのように再定義するのでしょうか？
何十年もの間、標準的なITパラダイムでは、物理インフラストラクチャを複製すること、つまり、セカンダリデータセンターの構築、冗長電源のプロビジョニング、地理的な分離の活用によって、レジリエンスが実現されると考えられてきました。クラウドへの移行によって、この負担はクラウドサービスプロバイダー（CSP）へと移りました。多くのビジネスリーダーは、クラウドの導入が可用性の保証と同義であると誤解していました。
クラウドインフラストラクチャのみに依存するリスクとは何ですか。
大手クラウドプロバイダーやSaaSプロバイダーは、マルチリージョンのフェイルオーバーや高可用性アーキテクチャに数十億ドルを投資していますが、単一障害点に対する脆弱性は依然として残っています。Border Gateway Protocol（BGP）ルートの設定ミス、DNSの名前解決の失敗、主要なハイパースケーラーリージョンでの連鎖的なAPIエラーが1つでも発生すると、何千もの組織が基幹システムから瞬時に切断される可能性があります。
この脆弱性は、必ずしもデジタルなものとは限りません。日常的な道路補修作業中にたった1人のバックホーオペレーターが地下の光ファイバー回線を切断してしまった場合、あるいは物理的な妨害行為の標的となった場合、エンタープライズとクラウドを結ぶライフラインは瞬時に断たれ、本来なら機能するはずのリモートリソースにまったくアクセスできなくなります。
このような場合、クラウドプロバイダーは内部では完全に稼働していても、エンタープライズのネットワークがプロバイダーのエンドポイントに到達できないため、サービスは事実上ダウンしていることになります。
回復力のあるネットワーク計画に適用される、中核的なセキュリティ原則とは何ですか？
これらのリスクに対処するため、事業継続計画には情報セキュリティとディザスタリカバリ（DR）の基本原則を組み込む必要があります。
重要な事柄のマッピング：現状の確認
問題を修正するには、まず実際に何を保護しているのかを把握する必要があります。つまり、事業の中核を担う絶対に停止できない部分を特定し、それらが依存するすべてのクラウドプロバイダーやSaaSツールまで遡って把握するということです。依存関係がどこにあるかわからなければ、保護することはできません。
存続のための方程式：計算が合わなくなる理由
セキュリティの世界には、ビジネスの存続に関わる基本原則があります。それは、最大許容停止時間（MTD）—損失を出しながら事業を継続できる絶対的な限界時間—が、技術的な問題を修正するのにかかる時間、すなわち目標復旧時間（RTO）と、データや従業員が通常の業務に戻るまでにかかる時間（WRT）の合計よりも長くなければならない、というものです。
MTD >= RTO + WRT
クラウドには、次のような落とし穴があります。接続が完全に失われた場合、接続の復旧は自社ではどうすることもできない可能性があるため、RTO（目標復旧時間）は無期限に延長されます。オフラインの代替手段がなければ、この方程式は完全に崩壊し、ビジネスは時間切れとなってしまいます。
グレースフルデグラデーション：「アイランドモード」
エンタープライズが外部世界との接続を失った場合、運用上の「島」となり、グレースフルにフェイルオーバーできなければなりません。ローカルネットワークは、外部クラウドとのハンドシェイクに依存することなく、容量を縮小した状態で、コア業務、生命維持、または収益を生み出すタスクをサポートする必要があります。
クラウドの切断は、重要インフラ業界にどのような影響を与えるのでしょうか？
業種や事業のあり方はそれぞれ大きく異なりますが、クラウド利用におけるレジリエンスの必要性は、多くの業界に共通するものです。以下に、クラウドからの切断が一部の重要産業に与える影響を詳しく示し、ローカライズされた運用の継続性が不可欠となる箇所を明らかにします。
クラウドの切断がビジネス継続性を脅かす仕組み
障害発生時における業界の重大な脆弱性のマッピング。
業界固有の脆弱性
ヘルスケアと臨床業務
病院では、電子カルテ（EHR）への迅速なアクセス、患者のリアルタイムな遠隔測定、自動薬剤払出棚の利用が、人命を左右します。クラウドでホストされているEHRへの接続が切断されると、臨床医は重要な患者の病歴、アレルギー、進行中の治療に関する情報を確認できなくなります。投薬ワークフローが滞り、患者の安全が直接的な危険にさらされます。
軍事および戦術的防衛
軍は、接続が拒否（Denied）、劣化（Degraded）、断続（Intermittent）、または制限（Limited）されるDDIL環境で日常的に活動しています。司令部、通信アレイ、戦術ロジスティクスシステムは、中央クラウドへの常時アップリンクがなくても確実に機能する必要があります。防衛アーキテクチャにおいて、外部のクラウドサービスへの強い依存関係は、国家安全保障上の深刻な脆弱性となります。
公益事業と重要インフラ
電力網、水処理システム、エネルギー輸送パイプラインは、監視制御・データ収集（SCADA）システムに依存しています。これらの産業用制御システムは、物理インフラストラクチャをローカルで監視および調整する必要があります。クラウドに接続された監視レイヤーがダウンした場合、壊滅的なシステム障害を防ぐために、ローカライズされたシステムは安全かつ自律的な状態を維持する必要があります。
製造業と産業オートメーション
現代のスマートファクトリーは、高速な産業用IoTネットワークと自動組立システムに依存しています。ごくわずかなネットワークの瞬断でも、ロボットの同期が失われたり、生産ラインが停止したりして、大きな無駄が生じる可能性があります。重工業における計画外のダウンタイムは、1分あたり数万ドルのコストを発生させるため、ローカルのEdgeコントローラーはリモートハンドシェイクなしで稼働する必要があります。
輸送および配送ロジスティクス
港湾、配送ハブ、国際的な海運会社にとって、物流のボトルネックは許されません。地域のクラウドサービスが停止した場合でも、無人搬送車（AGV）は安全な走行を継続し、マニフェストのスキャンを続行し、コンテナのルーティングシステムはトランザクションをローカルでキューに入れる必要があります。そして、WANリンクが復旧した際に非同期で同期処理を行います。
なぜアイデンティティが主要なセキュリティコントロールプレーンなのでしょうか？
現代のゼロトラストアーキテクチャでは、アイデンティティが主要なセキュリティコントロールプレーンとなります。組織は、耐障害性の高いオンプレミスアプリケーションを展開できます。それでも、アプリケーションがユーザー認証を到達不能なクラウドアイデンティティプロバイダー（IdP）に依存している場合、切断というイベントが発生すると機能的に役に立たなくなります。
クラウド障害時に標準的なリダイレクトフローが失敗する仕組み
クラウド障害発生時のリダイレクトフローの連鎖的障害。
一般的なクラウドベースのアイデンティティ展開では、Security Assertion Markup Language（SAML）またはOpenID Connect（OIDC）を使用したシングルサインオン（SSO）は、ユーザーのブラウザをアプリケーションとOktaの間でリダイレクトすることによって機能します。インターネットまたはSaaSの停止時：
- アプリケーションは、受信したアイデンティティのアサーションを検証できません。
- ユーザーのブラウザがクラウド認証エンドポイントを解決または到達できません。
- バックチャネルのトークン検証チェックが失敗します。
生き残るためには、エンタープライズネットワークを「アイランドモード」に戻す必要があります。つまり、Edgeでネイティブに有効なトークンを発行できるローカルディレクトリとローカルアイデンティティサーバーにフォールバックさせるのです。これは、従来のWebベースのアプリケーションとエージェント型AIの両方にとって重要です。エージェント型AIでは、エージェントがオンプレミスに存在し、オンプレミスのリソースにアクセスする必要がある場合があります。
Okta Local Authentication Serviceはどのように稼働時間を維持しますか？
アイデンティティの存続性に関するボトルネックを解決するため、OktaはOkta Local Authentication Serviceを開発しました。このサービスはOkta Access Gateway（OAG）に組み込まれています。OAGは、オンプレミスまたはハイブリッドクラウドに展開されるローカライズされたゲートウェイアプライアンスです。
このアーキテクチャでは、OAGはトラフィックをフィルタリング、認証してアプリケーションに渡す単なるリバースプロキシではありません。SAMLとOIDCを使用して、ローカルのエンタープライズアプリケーションのプライマリIdPとして機能します。
Okta Access Gatewayが停止中にローカル認証を維持する方法
Okta Access Gatewayのローカル認証を使用した復旧フロー。
オフライン移行のメカニズム
- 継続的なヘルスモニタリング：OAGは、設定可能なヘルスチェック間隔で、アップストリームのOkta Cloudテナントへの接続ステータスを継続的に監視します。
- 停止の検出：接続障害が設定されたフォールバックのしきい値を超えると、OAGはターゲットアプリケーションを自動的に切断認証モードに切り替えます。
- ローカルでの資格情報検証：ユーザーをOkta Cloudテナントにリダイレクトする代わりに、OAGはローカライズされたカスタムの非接続型サインインページを表示します。ユーザーが認証情報を入力すると、OAGはOkta AD/LDAPエージェントを介してクラウドと同期されているActive Directory（AD）やLightweight Directory Access Protocol（LDAP）などのローカルディレクトリーサービスに対して、その認証情報を直接検証します。
- ローカルポリシーの適用：OAGは、ローカルの非接続認証ポリシーを評価し、「非常時」に承認されたユーザーグループのみが重要なアプリにアクセスできるようにします。
- ローカルトークンの生成：OAGは、ローカルアプライアンスからアプリケーションに直接、暗号化署名されたSAMLまたはOIDCトークンを発行し、中断のないセッションアクセスを維持します。
ハイブリッドEdgeアーキテクチャの制限事項は何ですか？
WANやクラウドプロバイダーの障害の影響を軽減し、真のオペレーショナルレジリエンスを実現するには、多層的な戦略が求められます。Oktaがアイデンティティコントロールプレーンの強化に注力する一方で、基盤となるインフラストラクチャも同時に適応する必要があります。その結果、クラウドインフラストラクチャをローカルの物理サイトに直接拡張するハイブリッドEdgeトポロジーを導入するエンタープライズが増えています。
このパターンの主な例として、AWS Outpostsが挙げられます。これは、ネイティブのAWSサービス、API、セキュリティツールをお客様のオンプレミス施設に直接提供する、フルマネージドのハイブリッドソリューションです。
AWS Outpostsのサバイバビリティ特性
通常の運用条件下では、AWS OutpostsはアクティブなWANリンクまたはAWS Direct Connectを介して、親となるAWSリージョンに接続します。ただし、ローカルネットワーク接続の質が低下すると、Outpostsは次のようなアーキテクチャ上の動作を示します。
ローカルでの実行の継続性：Outpostラックで既に実行中のアプリケーションは、ローカルで実行を継続します。ローカルのクライアントデバイスから引き続きアクセスできます。
10ミリ秒未満のレイテンシー：ローカライズされたシステムは、1桁ミリ秒のレイテンシーでOutpostインフラストラクチャと対話するため、通常30〜100ミリ秒かかるクラウドのルーティングによるペナルティを回避できます。
ローカルデータのトラバーサル：ローカルデータベースやオンプレミスのレガシーシステム宛てのトラフィックは、すべてLGWを経由するため、WANの脆弱性に晒されることはありません。
Edgeの制限
AWS Outpostsはハイブリッドクラウドの展開を一歩前進させるものですが、ハイブリッドクラウドの根本的な限界も示しています。つまり、永続的、分離的、オフラインでの運用を想定して設計されていないのです。
- APIコントロールプレーンの機能低下：切断状態では、ローカルでの管理アクションが大幅に低下します。インスタンスを実行、開始、停止、または終了するためのAPI呼び出しは、コントロールプレーンが親のAWSリージョンに存在するため失敗します。
- ログと測定基準のキャッシュ制限：CloudWatchの測定基準とシステムログは、停止中にOutpostラックにローカルでキャッシュされます。ただし、このキャッシュの上限は7日間です。この期間内に接続性が復旧しない場合、重要な監査ログ、セキュリティ測定基準、ヘルスインジケーターは永久に失われます。
これは、エンジニアリングにおける重要な現実を浮き彫りにしています。つまり、ビジネス継続性を維持するために、組織はEdgeでのインフラストラクチャのホスティングだけに頼ることはできないということです。また、ローカルシステムに対してユーザーを認証・認可するために、回復力とEdgeでの存続性を備えたアイデンティティコントロールプレーンも必要です。
Okta Access GatewayをAWS Outpostインフラストラクチャ内で実行することで、WAN障害が発生した場合でも、重要なインフラストラクチャに対してEdgeでオフライン認証とアイデンティティを提供できます。
切断された認証ポリシーはどのように設定しますか？
回復力のあるアイデンティティの境界を構築するには、慎重な管理計画が必要です。OAGは、クラウドテレメトリから切断された場合でもセキュリティポリシーを維持できるよう、きめ細かいローカライズされた制御を提供します。
分断された認証ポリシー設計
管理者は、オフラインのシナリオに固有のルールを定義できます。例えば、組織は、オフラインアクセスを特権付きの緊急対応担当者に限定したり、代替のauthenticatorへのフォールバックを確保したりすることが考えられます。
Okta Access Gatewayで切断された認証ポリシーを構成する
切断モードの認証ポリシー設定
カスタムブランドのオーケストレーション
WANまたはクラウドの停止中は、ユーザーの混乱が大きな運用リスクとなります。OAGを使用すると、管理者はオフライン時のエクスペリエンスをカスタマイズして、環境が変更されたことをユーザーに明確に通知できます。
- 独自のブランディング：カスタムのブランドロゴや特定の運用カラーパレットを維持します。
- コンテキストに応じた警告：ローカライズされたバナーなど、ユーザー向けの専用インジケーターを表示します。例：「クラウドから切断されました。オプションが制限される可能性があります」このシンプルな機能を追加することで、パニックを軽減し、ヘルプデスクへのチケット件数を削減し、従業員が定められたオフライン業務のプロトコルに確実に従うようになります。
自動フォールバックおよび復旧のしきい値
「フラッピング」（インターネット接続が非常に不安定なためにOAGがオンラインモードとオフラインモードを短時間で頻繁に切り替える現象）を防ぐため、OAGはデュアルスレッショルド状態検出を利用します。
- Orgチェックの間隔：OAGがクラウドテナントの可用性をチェックする頻度（例：60秒ごと）。
- フォールバックのしきい値：切断モードをトリガーするために必要な、連続して失敗したチェックの回数（例：2回）。
- 復旧しきい値：オンラインモードに戻るために必要な、連続した正常なチェックの回数（例：4回）。この控えめな復旧パラメーターにより、認証ワークロードをクラウドに戻す前に、WANリンクが完全に安定していることを確認できます。
レジリエンスは戦略であり、機能ではありません。
組織のクラウド統合が深化するにつれて、サードパーティに起因する障害のリスクは飛躍的に増大します。サービス品質保証契約（SLA）のみに依存したり、クラウドネットワークが常に完璧であると期待したりするだけでは、真の事業継続性を実現することはできません。
世界トップクラスのレジリエントなビジネスを構築するには、リーダーは障害を想定した設計をしなければなりません。オフラインアクセスは、二次的な選択肢としてではなく、不可欠なアーキテクチャ戦略として取り組む必要があります。エッジプラットフォームモデルを導入し、ビジネスへの影響範囲を厳格に定め、Okta Local Authentication Serviceのようなテクノロジーを活用することで、現代の企業は自信を持ってクラウドの境界を越えることができます。これにより、たとえ世界がオフラインになっても、ビジネスを継続させることが可能になります。
ハイブリッドクラウドの境界を保護する準備はできていますか？
次回のWAN障害を待ってからディザスタリカバリ（DR）計画をテストするようなことは避けてください。Okta Access Gatewayデータシートをダウンロードして、既存のコードを変更することなく、オンプレミスアプリケーションへのアクセスを保護し、ハイブリッドクラウドを保護する方法をご確認ください。
