Summary
- 経済的単位は NAT ゲートウェイの料金ではない。顧客、銀行、サプライヤー、公的システムが既に認識しているプラットフォーム管理のパブリックアイデンティティを維持または置き換えるためのワークロード当たりのコストである。
- セキュリティと可観測性の記録は、パブリックアドレスを蓄積された証拠に変える。その証拠がプロバイダー割り当てのアイデンティティに結びつくと、移行によって属性と外部の信頼を再構築しなければならないため、現職のプロバイダーは交渉上の優位性を得る。
- BYOIP は、保有者の管理、宛先の受け入れ、ルーティング、テレメトリ、ロールバックがすべて証明された場合にのみ立場を改善する。ポータブルな証拠は、取引相手の承認を短縮し、アーキテクチャ上の主張からの離脱をテスト済みの選択肢に変えることができる。
買収はパブリックエッジを最後に見つける
統合会議は通常の自信から始まる。二つの事業が統合される。アプリケーションには所有者がおり、データストアには移行計画があり、インフラチームは仮想マシン、コンテナ、マネージドデータベースを望ましいクラウド環境に再作成する方法を示すことができる。調達部門は現職のサプライヤーとの困難な交渉を予想しているが、存亡をかけたものではない。取締役会は買収を承認した。その理由の一部は、統合後の企業がホスティングを簡素化し、重複ツールを削減し、新しいグループに適合しなくなった契約を整理できるからである。
部屋の空気を変える質問はコンピュートに関するものではない。それは調達側からのものだ。「推奨プラットフォームが商業条件を拒否した場合、買収したワークロードを契約更新日までに、顧客、銀行、サプライヤー、セキュリティ調査を壊すことなく別の場所に移行できるか？」最初の答えは展開可能な資産のリストである。二番目の答えは沈黙だ。なぜならパブリックエッジは同じ注意を払って棚卸されていないからである。支払いチェック、ソフトウェア更新、顧客ポータル、規制報告からの外向きトラフィックは、プラットフォーム管理のパブリックアドレスを通じて出ていく。外部の当事者はそれらのアドレスを許可し、監視し、既知の事業と関連付けてきた。ログ、ファイアウォールルール、インシデントファイルは、内部のワークロード名を、トラフィックを外界に提示したゲートウェイに結びつける。
これはクラウド NAT が小さなアーキテクチャ部品ではなく、交渉の場になる瞬間である。変換デバイスは理にかなっている。直接的な露出を減らし、プライベートなワークロードをプライベートに保ち、セキュリティチームにポリシーの集中点を提供する。経済的問題は異なる。少数のプラットフォーム管理のパブリックアイデンティティが多数のワークロードの信頼履歴を運ぶ可能性がある。それらのアイデンティティが移動できない場合、コードが他の場所で完全に動作しても、ワークロードは商業的に移動可能ではない。
これはエンドユーザーのキャリアグレード NAT と同じ問題ではない。リテールアクセスネットワークは加入者を共有パブリックアドレスの背後に圧縮し、属性、不正使用、サポート、アプリケーションの破損に対処する。クラウド NAT はエンタープライズとプラットフォームのアーキテクチャ内に存在する。そのハードコストは主に家庭の苦情や加入者ポートの検索ではない。購入者がパブリックエッジを提供するプラットフォームを変更したい場合に、外部に認識されているビジネスアイデンティティを維持するためのコストである。
これはクラウド依存に関する一般的な嘆きでもない。多くのクラウドサービスは、チームがプロバイダーのインターフェース、セキュリティ制御、デプロイ習慣を学習するため、切り替えコストを生み出す。パブリックアイデンティティは、認識が購入者-サプライヤー関係の外側に存在するため、より鋭い。銀行、公的機関、ソフトウェアサプライヤー、主要顧客は、どの調達決定がそれを生み出したかをずっと忘れた後でも、パブリックソースアドレスを信頼するかもしれない。Lu Heng のネットワークアイデンティティの経済学に関するノートは、番号を装飾的な技術ラベルではなく継続性の表面として扱っているため、ここで役立つ。一意性調整の権利章典は、共通レイヤーが管理を可読にし、使用を許可に変えるべきではないという制度的規律を提供する。
したがって、統合チームは新しい登録簿を必要とする。重要なワークロードごとに、どのパブリックアイデンティティが世界に面しているか、誰がそれを管理しているか、どの取引相手がそれに依存しているか、どのセキュリティ証拠がそれに依存しているか、そしてそれを維持または置き換えるために何が必要かを尋ねなければならない。その登録簿が存在するまで、移行計画は展開可能なコンピュートと移動可能な信頼を混同している。
買収設定は感情を取り除くので有用である。購入者はあるプラットフォームが流行しているかどうか、あるいは別のものが古いかどうかを議論しているのではない。不動産が合理化された場合に、買収した収益を保護できるかどうかを決定しているのである。顧客から静かに信頼されるようになったパブリックアイデンティティは、午後に再展開できるアプリケーションよりも価値があるかもしれない。したがって、慎重な統合チームはアドレスの継続性を、ドメイン管理、証明書の保管、支払い業者識別子、銀行の署名権限者のように扱う。つまり、誰がビジネスの公的な顔を変更できるのか、その権利を証明する証拠は何か、そしてその変更を急いで行わなければならない場合にどれだけの価値が失われるのかを尋ねる。
コスト対象はゲートウェイ料金ではなく外部の認識である
クラウドの請求書は間違った分母を奨励する。購入者にコンピュート、ストレージ、ネットワーク転送、ゲートウェイ時間、セキュリティサービス、サポートティアの比較を促す。その見方はコスト管理には必要だが、経済的なホールドアップを特定しない。依存関係はゲートウェイの行そのものではない。ワークロードが外界に受け入れられ、観察され、非難されるために使用する、組み立てられたパブリックアイデンティティである。
アウトバウンドのワークロードは独自のパブリックアドレスを持たないかもしれない。それは変換ゲートウェイに到達し、ゲートウェイは顧客、銀行、サプライヤー、または公的システムが受け入れたパブリックソースアドレスを提示する。同じアドレスがファイアウォールルール、不正防止例外、インシデントレポート、契約上のサポートノート、セキュリティベースラインに表示される可能性がある。プラットフォームはアカウント内のリソースを見る。エンタープライズはプライベートサブネットからの出口を見る。取引相手は既知の送信元を見る。調査者は属性境界を見る。これらは別々の資産ではない。それらは同じ外部認識の異なる見方である。
したがって、分子には明示的なプラットフォーム料金以上のものが含まれる。アドレスを維持または置き換えるために必要なエンジニアリング作業、トラフィックが受け入れられる前に必要な取引相手の承認、新旧のパスを一緒に実行しなければならない期間、二つの証拠ストリームを一貫性のある状態に保つためのコスト、そして購入者が契約更新前にこれらのタスクを完了できない場合に現職に支払われる交渉の譲歩を含む。金額を誤った精度に強制すべきではない。特定されたボトルネックを含むテスト済みの範囲は、カレンダーを管理する当事者を除外したきちんとした数字よりも正直である。
分母は二つの部分からなる。一つ目はワークロード当たりのコストである。共有エグレスアイデンティティは、一つのパブリックアドレスが多数の内部システムをサポートするため効率的に見えることがある。ただし、購入者が、アドレスが変更された場合に信頼されなくなるか追跡不能になるシステムを知っている場合にのみ効率的である。外部の許可リストを持たないバッチジョブは、取引相手が固定ソースを認識する支払いアプリケーションとは同等ではない。プールされたエグレスは、アドレス在庫を節約しながら事業中断を集中させる可能性がある。
二つ目は、行使可能な出口オプション当たりのコストである。ワークロードがポータブルであるという主張は、購入者が関連アイデンティティの管理、宛先による受け入れ、機能するルーティングと接続、存続するセキュリティ証拠、取引相手の移行計画、およびロールバックパスを示すことができなければほとんど意味がない。BTW によるルートオブジェクトガバナンスの経済学と財産インフラとしてのルーティングセキュリティの経済学の以前の分析は、アドレス使用に関するパブリックな証拠が商業的信頼に影響を与える理由を示している。クラウド NAT のバージョンはより狭いが具体的である。購入者は、認識されたパブリックアイデンティティがワークロードとともに移動できるか、あるいはプラットフォームがその認識の実質的な管理者になっているかを知らなければならない。
この会計処理は、良好なクラウド決定も保護する。一部のワークロードは、短命、低リスク、または再識別が容易であるため、プラットフォーム割り当てのアイデンティティを使用すべきである。他のものはそうすべきではない。統一されたルールは高価で粗雑である。重要なのは、展開図の優雅さではなく、蓄積する外部認識に従ってワークロードを分類することである。
分類は方向も記録すべきである。インバウンドのパブリックアイデンティティは、通常、顧客が名前、証明書、アドレス、ロードバランサー、またはコンテンツの正面玄関を通じてサービスに到達するため、可視である。アウトバウンドのアイデンティティは、しばしばより静かで危険である。なぜなら、それを受け取る取引相手によってのみ発見されるからである。サプライヤーポータルは、送信元アドレスが何年も前に作成されたファイルと一致するため、API コールを受け入れるかもしれない。顧客はそのアドレスを見ることはないかもしれないが、予告なく変更されると契約が失敗する可能性がある。したがって、コスト対象には、トラフィックを引き付けるパブリックエンドポイントと、他のシステムにトラフィックを受け入れるよう説得するパブリックソースの両方が含まれる。
変換はアイデンティティがプラットフォーム管理下にある場合に権力となる
変換は技術的行為である。変換されたパブリックアイデンティティに対するプラットフォームの管理は経済的ポジションである。この記事は NAT が良いか悪いかを問うているのではないため、この区別は重要である。変換は露出を減らし、プライベートアドレッシングを簡素化し、セキュリティチームに管理可能なパブリックエッジを提供できる。問題は、そのエッジによって提示されるパブリックアドレスがサプライヤーのアドレス経済に属し、購入者が外部の信頼を再構築することなく持ち去ることができない場合に始まる。
通常のクラウド依存は通常、サプライヤー関係の内部にある。データベースインターフェースは別のデータベースインターフェースとは異なる。監視ツールは独自の言語を持つ。セキュリティ製品は特定の形式でルールを保存する。これらの違いは高価になりうるが、多くの場合、エンジニアリング、再トレーニング、契約管理によって解決できる。パブリックアイデンティティは外部の支持者を追加する。サプライヤーは移行をブロックする必要はない。他の当事者が既にサプライヤー管理のエッジを認識しているため、交渉力を保持できる。
顧客サポートシステム、文書提出ツール、サプライヤーAPI がすべてマネージド変換ゲートウェイを経由する地域エンタープライズを考えてみよう。プラットフォームはエンタープライズを強制していない。有用なサービスを提供している。サプライヤーは優れたセキュリティと信頼できるサポートを持つ強力なオペレーターであるかもしれない。しかし時間が経つにつれて、ゲートウェイのパブリックアドレスはサードパーティのファイルに埋め込まれる。調達部門がワークロードの移行を望むとき、二つのゲートウェイ製品を比較しているのではない。すべての重要な取引相手に異なる公的な顔を認識するよう依頼するか、別のプラットフォームにエンタープライズが管理するアイデンティティを受け入れるよう依頼しているのである。
これがサービス依存とアイデンティティ依存の違いである。サービス依存はアプリケーションが再構築可能かどうかを問う。アイデンティティ依存は、再構築後に世界がまだ誰と話しているのかを知っているかどうかを問う。最初の質問は主にエンジニアリングと調達に属する。二番目は調達、法務、セキュリティ、顧客、財務に属する。
このメカニズムは、LACNIC のクラウドプロバイダーアドレス権力に関する隣接する BTW の作業で既に現れているが、NAT バージョンは変換が認識を集中させるため、独自の扱いに値する。可視アドレスを持つパブリックウェブサイトは気づかれる可能性が高い。企業間トラフィックに使用される静かなエグレスアドレスは、アプリケーションエステートの背後に何年も存在するかもしれない。購入者は、銀行統合、支払いゲートウェイ、税務ポータル、マネージドセキュリティレビューが、買収のタイムラインで古いパブリックソースが消えられないと言ったときに初めてそれに気づくかもしれない。
プラットフォームの権力は、それが見えないままでいる場合に最も強力である。購入者がゲートウェイ料金のみを見ている場合、サプライヤー関係は競争可能に見える。購入者がそのゲートウェイに付随する外部認識を見ている場合、関係は継続性の取引になる。サプライヤーは依然としてビジネスに値するかもしれないが、今度は誰も価格付けしなかったアドレス記憶ではなく、サービス価値でそれを維持しなければならない。
これがプロバイダー中立的な言語が重要である理由である。このメカニズムは一つのハイパースケールサプライヤー、一つのマネージドサービスブランド、または一つの商業モデルに固有のものではない。パブリックアドレスプール、アカウント管理、ゲートウェイサービス、セキュリティ証拠を持つプラットフォームは、顧客がアプリケーションを所有している場合でも、外部認識の管理者になることができる。したがって、この記事は特定のプラットフォームの価格設定や機能比較を避ける。製品メニューは変わる。永続的な問題は、購入者が認識されたパブリックアイデンティティを提供の変更を通じて持ち運べるか、それとも各外部当事者が新しいプラットフォーム管理の顔を信頼するよう説得されなければならないかである。
共有エグレスは無関係なワークロードを一つの交渉面に結びつける
共有エグレスの効率性はその危険でもある。単一のゲートウェイまたは少数のパブリックアイデンティティのセットは、相互に商業的関係のない多数のワークロードグループのトラフィックを運ぶことができる。顧客ポータル、ベンダー更新プロセス、従業員ツール、規制報告サービス、アナリティクスコネクターは、アドレス経済と運用の簡素化のために設計されたアーキテクチャであるため、同じパブリックソースを共有する可能性がある。導入時には賢明に見える。出口では、それらのカレンダーを結びつける。
最も弱い依存関係がゲートウェイを所定の位置に固定する可能性がある。長い承認プロセスを持つ顧客、保守的なファイアウォール変更ウィンドウを持つサプライヤー、受け入れが遅い公的セクターシステム、または履歴証拠を必要とする調査が、ほとんどのワークロードがもはや必要としないアドレスの廃止を妨げる可能性がある。購入者はほぼすべてのコンピュートを移動し、まだ変更を受け入れていない最後の取引相手のために古いパブリックエッジを維持するために支払い続けているかもしれない。
これはデュアルスタックのコスト話ではない。問題は、すべての顧客やアプリケーションに対して二つのアドレスファミリーを維持しなければならないことではない。プラットフォーム管理のパブリックアイデンティティが、異なるビジネスクロックを持つワークロードの共通表面になっていることである。低リスクのサービスは数日で移動する準備ができているかもしれない。支払い統合は数週間の証拠と承認を必要とするかもしれない。規制対象の顧客は署名入りの通知とテストウィンドウを必要とするかもしれない。セキュリティ調査は、移行計画が予想していたよりも長く古いログを解釈可能に保つことを必要とするかもしれない。
したがって、調達部門はワークロードをアプリケーション所有者やクラウドアカウントではなく、パブリックアイデンティティの依存関係によってグループ化すべきである。登録簿は、どのワークロードがエグレスアイデンティティを共有しているか、どの外部当事者がそのアイデンティティを認識しているか、どの変更に事前通知が必要か、そしてどの証拠を切り替え後に保持しなければならないかを特定すべきである。共有ゲートウェイは、購入者がそれを共有解除するコストも知っている場合にのみ安価である。
顧客継続性に関する以前の BTW 作業は、別の角度から同じ点を述べている。ネットワーク関係は、顧客がサービスに関するアイデンティティの前提を再構築することなく継続できる場合に価値がある。クラウド NAT はその継続性を保護するか、あるいはそれを従属させることができる。違いは、エンタープライズがパブリックアイデンティティと証拠を、その背後で提供を移動するのに十分に管理しているかどうかにある。
アーキテクチャの対応は選択的な分離である。エンタープライズはすべての内部システムに専用のパブリックアドレスを必要としない。外部の信頼関係と一致する移行グループが必要である。永続的な取引相手、遅い承認、または高い証拠義務を持つワークロードは、共有ゲートウェイが整っているからという理由だけで、使い捨てのワークロードと無造作に混ぜるべきではない。依存度の低いシステムは、プラットフォーム割り当てのエグレスの背後に留まることができる。依存度の高いシステムは、管理されたアイデンティティ、明示的な移行条件、またはプラットフォームがレバレッジを保持するという価格付けされた受容のいずれかを必要とする。
これがコストを削減する最初の実用的な方法である。更新争いが起こるまで、どの無関係なシステムがパブリックな顔を共有しているかを見つけるのを待ってはいけない。信頼表面が購入者自身のアーキテクチャによって書かれた身代金メモになる前に、信頼表面を分割せよ。
分割は技術的な整然さではなく、ビジネス上の結果によって導かれるべきである。低リスクのテレメトリを送信するワークロードは、受信システムが同じグループによって所有されている場合、新しい送信元アドレスを許容できる。税務申告、決済指示、医療更新、またはサプライヤー注文を提出するワークロードは、はるかに遅い変更プロセスを必要とするかもしれない。両方を混在させる共有ゲートウェイは、低リスクシステムを高リスクのタイムテーブルに乗客にし、高リスクシステムを同じパブリックソースを使用するすべての小さな実験の人質に変える。優れたアーキテクチャはこれらのカレンダーを別々にする。
サプライヤー割り当てアドレスはビジネスクレデンシャルに熟成する
プラットフォームから供給されるアドレスは利便性として始まる。それはすぐに利用可能であり、サプライヤーによって管理され、最小限の交渉でサービスに付けられるかもしれない。それは多くのプロジェクトにとって合理的なエントリーの選択である。経済的変化は時間とともに起こる。アドレスは参照、承認、評判、制度的記憶を集める。それは購入者が独立して管理していなくてもビジネスクレデンシャルになる。
クレデンシャルは形式的ではなく実用的である。パートナーはアドレスを許可リストに記録する。不正システムはその振る舞いを学習する。サポートデスクはそれをトラブルシューティングノートに書き込む。セキュリティチームはそれを内部ログに結合する。サプライヤーのマネージドサービスはそれを既知の送信元として扱う。顧客はトラフィックがそこから発信されることを示す文書を受け取る。新しい参照のたびに、アイデンティティは購入者にとってより価値が高くなる一方で、プラットフォームの接続に対する管理は変わらない。
置き換えが常に悪いわけではない。古いアドレスに評判の問題や悪い履歴がある場合、新しいパブリックアイデンティティはよりクリーンかもしれない。逆に、有用な履歴を持つアドレスは、取引相手が既にそれを学習しているため価値がある可能性がある。エンタープライズはいずれにせよ証拠を必要とする。BTW のアドレス評判汚染の経済学の分析は、評判が単一のクリーンな台帳エントリーだけでは決着しないため関連性がある。プラットフォーム、取引相手、フィルタリングシステムはすべて異なる履歴を観察する可能性がある。
これが「自分のアドレスを持ち込む」という考えを、プラットフォーム機能リストのバッジではなく、管理の決定として扱うべき理由である。独自の認識されたアイデンティティを持つ購入者は、提供を変更しながら取引相手の信頼を維持できるかもしれない。そのようなアイデンティティを持たない購入者は、サプライヤーの公的な顔を借りる。どちらの選択も合理的であり得るが、混同すべきではない。前者はアイデンティティをプラットフォームに認められたエンタープライズ資本として扱う。後者はアイデンティティをプラットフォームサービスの一部として扱う。出口の経済学は完全に異なる。
買収はこの誤りを特にコストのかかるものにする。ターゲット企業は、統合後に冗長に見えるアドレス、関係、承認を保持している可能性がある。購入者の推奨プラットフォームの背後にすべてを統合すると、運用を簡素化しながら独立したアイデンティティオプションを破壊する可能性がある。したがって、デューデリジェンスファイルは、どのアイデンティティがサプライヤー割り当てか、どれが買収された事業によって管理されているか、どれが価値ある取引相手の履歴を持っているか、そしてどれが移行ハンドルとして維持され得るかを尋ねるべきである。外部の記憶を理解する前にパブリックアイデンティティを廃止すると、シナジーが将来の依存に変わる可能性がある。
同じ規律が、残さなければならないプラットフォーム割り当てアドレスにも適用される。ワークロードがサプライヤーアイデンティティを使用する理由が代替案にコストをかける価値がないためである場合、契約は終了、停止、紛争、移行時に何が起こるかを述べるべきである。ビジネスクレデンシャルになったパブリックアドレスは、その下のサービスラインが管理上と説明されたからといって消えるべきではない。サプライヤーは自身のプールの永続的な移植性を負わないかもしれないが、購入者はクレデンシャルが依存関係に熟成する前に置き換えパスを知るべきである。
クレデンシャルが古ければ古いほど、購入者はカジュアルな保証をより不信に思うべきである。サプライヤーは新しいアドレスが迅速に取得可能だと言うかもしれないし、それがプラットフォーム内では真実かもしれない。それは公的機関、支払いパートナー、顧客セキュリティチームが代替案を迅速に受け入れるかどうかには答えない。経過時間は最速のプロビジョニングインターフェースではなく、最も遅い認識当事者によって制御される。したがって、調達部門は割り当て速度と認識速度を区別すべきである。前者はサプライヤーの製品運用に属する。後者は古いアイデンティティを学習した取引相手の市場に属する。
セキュリティ証拠が現職のパスを放棄しにくくする
パブリックアイデンティティは信仰ではなく証拠を通じて信頼される。セキュリティチームは、ログ、アラート、調査がパスの周りに蓄積されているため、どのパブリックソースアドレスがどの内部ワークロード、アカウント、ユーザー、インシデントに対応するかを知っている。移行中、購入者はパケット到達可能性以上のものを維持しなければならない。変更前、変更中、変更後に何が起こったかを説明する能力を維持しなければならない。
この証拠負担はアドレス変更自体よりも大きいことが多い。新しいパスは一般的に同等のセキュリティサービスを持っているかもしれないが、古いパスを使えるようにした特定の履歴がまだ欠けている。検知ルールは現職プラットフォームからのフィールドに依存するかもしれない。調査は、他の場所で再現するのが難しい方法でゲートウェイログをワークロードメタデータに結合するかもしれない。保持期間が異なるかもしれない。エクスポート形式は、インシデント後にのみ重要だったコンテキストを省略するかもしれない。取引相手は、古いソースが何年もの通常の振る舞いを運んでいたときに、どのように新しいソースからのトラフィックを信頼できるかを尋ねるかもしれない。
現職は、それを利用しなくてもこの履歴から利益を得る。エンタープライズがクリーンな証拠ブリッジを示せない場合、去ることは無謀に見える。セキュリティリーダーシップは、サプライヤーを愛しているからではなく、属性が弱い期間を受け入れられないため、移行を遅らせるかもしれない。コンプライアンスチームは新旧のログの照合を要求するかもしれない。主要顧客は、新しいパブリックアイデンティティからのトラフィックがブロックされたり誤って属性付けされた場合の責任を誰が負うのかを尋ねるかもしれない。それらの質問は合理的である。それらはまた交渉力でもある。
証拠ブリッジは、購入者が更新圧力を受ける前に設計されるべきである。現在のパブリックアイデンティティ、それに関連するワークロード、その背後の内部ソース、関連する取引相手、それを解釈するセキュリティツール、カットオーバー後も存続する保持義務を記録すべきである。次に、宛先環境で新規または保持されたアイデンティティをテストし、ログを比較し、例外を確認し、ギャップに対する責任を割り当てるべきである。ブリッジは儀式的なリスク文書ではない。それはエンタープライズが調査能力を放棄することなく去ることができるという証明である。
ルーティングとセキュリティの公開は別の層を追加する。ROA 失効リスクの経済学、IRR データベース脆弱性の経済学、DNS 委任権力の経済学に関する以前の BTW 分析は、管理状態が依存当事者によって使用される場合に運用上重要になりうることを示している。クラウド NAT の設定では、購入者はどのレコードと表明がパブリックアイデンティティを支えているか、そしてどの機関またはサプライヤーがそれらを変更できるかを知る必要がある。
規律は単純である。顧客ファイルやセキュリティ検知に配置するほど重要なパブリックアイデンティティは、継続性ファイルを持つほど重要である。そのファイルはサプライヤーの変更を生き延びるべきである。それができない場合、購入者はワークロードをプラットフォーム依存として扱い、依存関係を正直に価格付けすべきである。
継続性ファイルには通常の状態だけでなく例外も含めるべきである。セキュリティチームはしばしばインシデント、一時的なブロック、不正使用苦情、緊急許可リスト、顧客エスカレーションから最も多くを学ぶ。それらの記録は、単になぜ信頼されているかではなく、なぜアドレスが慎重に信頼されているかを説明する。アドレスを保持してもインシデント履歴を失う移行は、依然として防御を弱める可能性がある。アドレスを置き換えても証拠を運び、取引相手に通知し、古いログを検索可能に保つ移行は、文書化が不十分な名目上安定したパスよりも安全かもしれない。重要なのは継続性そのものを崇拝することではない。継続性が重要である理由を維持することである。
顧客管理アドレスには形容詞ではなく受け入れが必要
顧客管理のパブリックアイデンティティは、それが受け入れられた場合にのみ価値がある。エンタープライズによって管理されるプレフィックスは外部認識を維持するかもしれないが、それでも宛先プラットフォームによって認められ、関連するネットワークによって運ばれ、意図されたサービスに添付され、取引相手によって信頼されなければならない。それをポータブルと呼ぶことはポータブルにしない。ポータビリティはテストによって証明される関係である。
受け入れの質問は具体的な形で尋ねられるべきである。どの管理範囲が宛先で使用できるか？どのトラフィック方向がサポートされているか？どのレコードが管理を証明するか？どのルートとセキュリティの表明が存在しなければならないか？プラットフォームが範囲を拒否、アナウンスを停止、または変更を要求した場合はどうなるか？競合する使用を生み出すことなく範囲を移行のためにステージングできるか？運用管理がある環境から別の環境にいつ移ったかを示す証拠は何か？プラットフォームの受け入れプロセスがカットオーバーを遅らせた場合、誰が支払うのか？
これらの質問はプラットフォームに対する不満ではない。顧客管理のアドレス空間をアナウンスまたは添付するプラットフォームには正当な責任がある。ルーティングの安定性を保護し、不正使用を防ぎ、権限を確認し、自身のネットワークとの競合を避けなければならない。重要なのは、受け入れが市場の一部であるということだ。購入者のアドレス資本は、他の当事者が予測可能な条件下でそれを認識する場合にのみ価値がある。
LARUS Oneの継続性のアイデアは、特定のサービスを購入する命令としてではなく、類推としてここで有用である。それはパブリックネットワークアイデンティティを配信パスから分離する。Lu Heng のLARUS One と顧客継続性に関するより長いノートは、パブリックアイデンティティが壊れるべきではない一方で、配信が変わりうる理由を説明する。クラウド NAT を使用するエンタープライズにとって、同じ論理が調達テストになる：ビジネスは、それを運ぶインフラを変更しながら、認識されたパブリックアイデンティティを維持できるか？
受け入れはまた購入者を律する。エンタープライズは、自身の記録、ルーティング衛生、セキュリティ表明、不正使用連絡性、取引相手通知を怠りながら独立を要求することはできない。保有者の管理は義務を生み出す。薄い調整モデルは責任からの逃避ではない。それはリソースを運用する当事者に責任を置き、プラットフォーム、キャリア、レジストリを定義されたレビュー可能な役割の内側に保つ。
実用的な成果物は受け入れパックである。これには管理の証明、現在の記録、ルートとセキュリティの証拠、認可された連絡先、変更履歴、アドレス評判ノート、取引相手依存リスト、テスト結果、撤回手順が含まれる。これは、宛先がフォレンジック調査なしでアイデンティティを評価できる程度に最新に保たれるべきである。更新前にパックを組み立てられない場合、購入者はまだ行使可能なオプションを持っておらず、願望を持っている。
その区別が交渉力が変化する場所である。テスト済みの宛先、受け入れられたアイデンティティ、マッピングされた取引相手移行を持つ顧客に直面するサプライヤーは、現実的な代替案と競争しなければならない。「ポータブル」と書かれたスライドのみを持つ顧客に直面するサプライヤーは、脅威を割り引くことができる。
受け入れは外部からもサンプリングされるべきである。宛先プラットフォームは範囲を受け入れるかもしれないが、重要な顧客は、自社のセキュリティチームが追加の評判チェックを使用するため、依然として変更を拒否するかもしれない。キャリアはルートを運ぶかもしれないが、マネージドセキュリティサプライヤーはポリシーを更新する前に別個の証拠を必要とするかもしれない。レジストリ記録は管理を示すかもしれないが、金融取引相手は契約上の通知とテスト取引を望むかもしれない。購入者は一つの成功した証明をチェーン全体と混同すべきではない。ポータビリティは、収入を停止させうるすべての当事者がアイデンティティを受け入れたか、テスト済みの変更パスを割り当てられた場合にのみ現実になる。
バンドルは出口シーケンスが消えるまで有用である
クラウドバンドルは統合に価値があるために存在する。マネージド変換ゲートウェイは、顧客がすべての部品を組み立てることなく、ルーティング、ロギング、セキュリティポリシー、スケーリング、サポート、アカウント管理と連携できる。すべてのバンドルを罠として扱うのは悪い経済学である。購入者は、調整コストを削減し、困難な運用をうまく行う可能性のあるサプライヤーに委ねるため、統合サービスを選択する。
リスクは、バンドルが出口シーケンスを見えなくするときに現れる。パブリックアイデンティティは一つのサービスを通じて添付され、別のサービスを通じてログに記録され、アカウント管理によって統治され、商業ティアを通じてサポートされ、セキュリティ製品によって保護されるかもしれない。契約はこれらを別々の行として説明するかもしれないが、移行はそうできない。割引はより広範なコミットメントに報いるかもしれない。サポートはより広い支出の維持に依存するかもしれない。ゲートウェイアドレスは請求書では小さく、出口問題では大きいかもしれない。
これがクラウドサービス間の価格比較が誤解を招く可能性がある理由である。より安価なゲートウェイは、新しいパブリックアイデンティティ、新鮮な取引相手の承認、より弱い証拠、より長い並行稼働を必要とする場合、安価ではない。より高価なサプライヤーは、管理されたアイデンティティを受け入れ、ログを保持し、段階的な撤退をサポートし、拒否のレビュー可能な理由を提供する場合、コストが低いかもしれない。調達は、パケットが通過するコンポーネントの価格だけでなく、ワークロード周りのアイデンティティ移行コストを比較すべきである。
契約条件はバンドルを露呈することができる。購入者は、パブリックアイデンティティが撤回される前の事前通知、終了後の関連ログへの継続アクセス、段階的な顧客管理アイデンティティへの支援、明確な停止基準、エクスポート可能なセキュリティ証拠、並行運用中の指定サポート、提案されたアドレスを拒否する理由を要求することができる。また、古いパブリックエッジを生かし続けることを実質的な目的とする単一のコミットメントに巻き込まれるのではなく、競争可能でなければならないサービスを特定することもできる。
責任は支配に従うべきである。レジストリ権力と責任に関する Lu Heng の議論は番号リソース層のために書かれているが、運営原則は伝わる。重要なパブリックアイデンティティ機能を管理する当事者は、説明のつかない中断からの害を他人の管理上の不便として扱うことが許されるべきではない。プラットフォーム、エンタープライズ、キャリア、レジストリ、取引相手は異なる役割を占める。契約はそれらの役割を見えるようにすべきである。
拒否には特別な注意が必要である。宛先は有効な技術的またはセキュリティ上の理由で管理範囲を拒否するかもしれない。それでも購入者がテストできる理由を提供すべきである。決定がパブリックアイデンティティが移動できるかどうかを決める場合、「サポートされていない」では不十分である。レビュー可能性は裁量を管理されたリスクに変換する。それがなければ、購入者は拒否が技術的なものか、商業的なものか、単に現職のアドレス経済を保護する製品境界なのかを見分けることができない。
目標はコストのかからない柔軟性ではない。目標は、購入者が実際のサービス価値と実際の移行サポートに対して支払い、サプライヤーが有用な統合を、あらゆる商業的挑戦を生き延びるアイデンティティの保管に静かに変換できない相互的な運用取り決めである。
ここでも調達は割引と依存を分離すべきである。コミットメント支出割引は、購入者がサプライヤーの統合エステートを本当に望んでいる場合に合理的であり得る。割引が、購入者がパブリックエッジを離れられないためにのみ手頃である場合、それは危険である。更新書類は、どのサービスがパフォーマンスのために保持されるか、どのサービスが移行証拠がまだ準備できていないために保持されるか、そしてどのサービスが取引相手が移動される間、外部に認識されたアイデンティティを生かし続けるためだけに保持されるかを述べるべきである。その正直さは、依存関係を一時的で、測定可能で、所有されたものにし、ブレンドされた商業的節約の内側に隠されないようにする。
LACNIC は携帯可能な証明としてのみ重要
この連鎖における LACNIC の役割は薄く、正確で、有用であるべきである。それはクラウドゲートウェイを設計したり、エンタープライズワークロードを運用したり、銀行のファイアウォールを承認したり、どのサプライヤーが契約に値するかを決定したりしない。その経済的に価値ある機能は、ラテンアメリカとカリブ海地域において、一意のパブリック番号リソース管理を判読可能にすることである。その証明は、プラットフォーム、貸し手、取得者、取引相手の検証コストを削減することができる。
有用なレジストリは信頼できる台帳である。それは競合する主張を防ぎ、正確な保有者記録を維持し、連絡可能性をサポートし、関連する履歴を保持し、依存当事者が理解できる形でセキュリティ隣接の事実を公開する。宛先プラットフォームが顧客管理アイデンティティを評価するとき、エンタープライズが管理を示せるかどうか、そして記録が一貫しているかどうかを知る必要がある。貸し手が継続性を評価するとき、ビジネスがサプライヤー割り当てアドレスのみに依存しているのか、それとも認識されたアイデンティティを他の場所に持ち運べるかを知る必要がある。取得者がターゲットを調査するとき、永続的なアイデンティティを、アカウントとともに消えるサービス成果物と区別する必要がある。
有害な拡大は、記録保持が正当な使用に対する許可として扱われるときに始まる。エンタープライズがクラウドプラットフォーム、マネージドプロバイダー、地域キャリア、または独自のネットワークを通じてパブリックアイデンティティを使用するかは、主に商業的および運用的な決定である。LACNIC の関心は、一意性、正確性、連絡可能性、関連記録の完全性であるべきである。レジストリ継続性の誤謬はこの点を直接述べている：台帳とその技術的機能には継続性が必要である；ゲートキーパーのより広範な権限の主張はそうではない。
この薄さはプラットフォームだけでなく保有者も助ける。明確な台帳は、プラットフォームがより低い不確実性で顧客管理アイデンティティを受け入れることを可能にする。裁量的または曖昧な層は、プラットフォーム自身のプールの方が消費しやすいため、サプライヤー割り当てアイデンティティをより魅力的にする。結果は逆説的だろう：より多くの管理を行使しようとするレジストリは、意図せずしてエンタープライズをプライベートプラットフォームアイデンティティの奥深くに押しやる可能性がある。
Running-Code Primacyの実行ネットワークテストは正しい境界である。実行ネットワークは一意性、正確な記録、セキュリティ関連証拠、連絡可能性、移転記録、継続性を必要とする。クラウド移行、買収統合、サプライヤー切り替えが商業的に徳があるかどうかを地域機関が判断することを必要としない。番号リソースは政治的財産ではない、厚いガバナンスは二重の搾取になるに関する Lu Heng のノートは、IPv4 が資産グレードのインフラになった時点で、この区別がなぜより鮮明になるかを説明する。
実用的な要請は携帯可能な証明である。保有者は、通常の商業的使用を広範な制度的裁量に依存させることなく、管理を示し、運用上の事実を更新し、変更を記録し、関連するセキュリティ状態を維持し、紛争を隔離できるべきである。最小初期仕様、ローカライズされた将来の決定、自発的採用の設計原則はこの問題に適合する：共通でなければならないものを調整し、残りはビジネスリスクを負う当事者に委ねる。
クラウド NAT の経済学にとって、これは LACNIC が証明に関する不確実性を低下させるべきであることを意味する。それは購入者のプラットフォーム選択における別の参加者になるべきではない。
薄い証明の役割はまた、LACNIC を不可能な期待から保護する。プラットフォームが独自の技術的理由でエンタープライズ管理範囲を拒否する場合、LACNIC はプラットフォームの製品境界について非難されるべきではない。購入者が取引相手の維持に失敗した場合、LACNIC は購入者の調達怠慢を治すよう求められるべきではない。レジストリ記録が正確でポータブルであれば、それは共通層に属する部分を果たしたことになる。残りの決定は、契約、ネットワーク、顧客、取引における責任を持つ当事者によってなされるべきである。
NRS は保有者側の交渉力を強化すべきであり、新たな中心を売るべきではない
この設定における建設的な制度的方向性は、Number Resource Societyを通じた保有者側の調整であり、その主張でさえ狭くなければならない。NRS はクラウドプラットフォームでも、レジストリの代替でも、価格設定委員会でも、アドレスプールでも、プラットフォーム依存に対する普遍的な回答でもない。その価値は、保有者が証明、移植性、レビュー、継続性を、より強力な取引相手との交渉においてより使いやすくするのに役立つ場合にのみ存在する。
その役割は実用的である。メンバーは、異なるプラットフォームや仲介者によって要求される証拠を、その演習を製品リストに変えることなく比較することができる。彼らは、証明がポータブルでなかったためにアイデンティティ継続性が失敗した場合、繰り返し発生する拒否パターン、不明瞭な責任条件、事例を特定することができる。ケースアーカイブは、検証された事実を主張から分離し、商業的に機密性の高い情報を保護する場合、孤立した経験を制度記憶に変えることができる。NRS Shieldのようなツールは、保有者にとって継続性とレビューをより強制力のあるものにし、別の依存層を追加するのではなく、その場合にのみ重要である。
NRS にはガバナンス機能もある。レジストリ、プラットフォーム、仲介者がパブリックアイデンティティの使用を停止、拒否、条件付けできる場合、保有者はルール、要求される証拠、レビュールート、責任境界を知る必要がある。グローバルプラットフォームと交渉するか、レジストリ側の不確実性に対応する孤立したエンタープライズは、裁量に挑戦するための言語と比較証拠を欠くかもしれない。保有者組織は、基礎となるビジネスを統治すると主張することなく、その孤立を減らすことができる。
これは販売論法ではない。NRS は、行使可能な出口オプションのコストを下げるかどうかによって判断されるべきである：より良い証明パック、より明確な受け入れ期待、より強いエスカレーション、より少ない重複した法的作業、より良い継続性言語、より信頼できる代替案。それらの効果を示せない場合、アーキテクチャの外側に留まるべきである。ポジティブな将来の方向性は制度の膨張を意味しない。それは単一点の裁量を決定的でなくすることを意味する。
なぜ NRS が存在するのかに関する Lu Heng のノートは、分散化をスローガンではなくシステム問題として枠付けている。それがここでの唯一有用な読み方である。購入者はクラウドプラットフォームとレジストリの上の新たな権威の中心を必要としていない。管理を証明し、アイデンティティを保持し、代替案をテストし、強力な取引相手がノーと言ったときに理由を受け取る能力を必要としている。
したがって、NRS は調達ファイルの端に属し、ネットワーク図の中央ではない。それは保有者のための共有言語と証拠実践を提供することができる。どのワークロードが移動すべきか、どのプラットフォームが勝つべきか、どの商業モデルが道徳的に好ましいかを決定すべきではない。エンタープライズは、サービス、顧客、資金調達の結果を負うため、それらの決定を保持する。
その抑制が NRS の役割を信頼できるものにする。すべてのアドレス、クラウド、移行問題を解決すると約束する新しい機関は、それが批判する過剰を単に再現するだけだろう。証明規律を改善し、裁量のパターンを記録し、レビュー可能性をサポートし、メンバーが受け入れ要件を比較するのを助ける保有者側の組織は、取引を所有すると偽ることなく、交渉のコストを削減することができる。プラットフォームとレジストリが多くの個々の保有者よりも強い市場では、控えめな調整が大げさな言葉よりも価値があるかもしれない。
オプションは更新圧力の前に測定されなければならない
購入者のレバレッジは生産が移動する前に変化する。テスト済みのオプションは、現職が、顧客が自身のパブリックエッジによって閉じ込められていないことを見ることができるため、交渉に影響を与える。テストされていないオプションは影響を与えない。それは取締役会を安心させるかもしれないが、更新日が近いときにサプライヤーの行動を変えることはない。
測定は因果連鎖に従うべきである。第一に、どのパブリックアイデンティティが重要で誰がそれを管理しているかを証明する。第二に、それらのアイデンティティとそれらを認識する取引相手によってワークロードをグループ化する。第三に、宛先がエンタープライズ管理アイデンティティを受け入れるか、またはどのような置き換えアイデンティティが必要かをテストする。第四に、ルーティング、接続、セキュリティ証拠、可観測性を再現する。第五に、重要な取引相手の受け入れ、またはそれを取得するために必要な変更プロセスを確認する。第六に、カットオーバー、オーバーラップ、ロールバックを定義する。順序は重要である。なぜなら各段階が遅延の異なる理由を取り除くからである。
この測定は、地域オペレーターが新しい需要を契約を収益に変えるのに十分な速さで展開可能なパブリックアイデンティティと一致させなければならない成長圧力の問題とは異なる。ここでは、エンタープライズは既にワークロードと外部認識を持っている。その質問は、その認識がクラウドエステートの存続期間中にプラットフォーム管理になったかどうかである。コストは新規顧客のための限界アドレスではない。既存のビジネスアイデンティティをサプライヤーの挑戦、移行、買収を通じて運ぶためのコストである。
測定はまたデュアルスタックの請求書とも異なる。問題は、顧客とアプリケーションのために二つの到達可能性システムを存続させる年間コストではない。プラットフォーム配信パスを変更しながら、認識されたパブリックアイデンティティを維持できるというオプション価値である。IPv6 は将来の依存を減らすかもしれない。しかし、それ自体では、銀行、顧客、監査人を説得して、購入者のタイムテーブルで変更されたパブリックエグレスパスを認識させることはない。
財務チームは結果を信頼水準付きの範囲として記録すべきである。重要なワークロードグループごとに、アイデンティティを維持する、アイデンティティを置き換える、または限定的な移行のために現職を保持するのに何がかかるか？どのコストがエンジニアリング、取引相手の承認、法的レビュー、セキュリティ証拠、並行運用、顧客通知、商業的譲歩か？どれが一時的で、どれが出口オプションを新鮮に保つために再発するのか？BTW の相互接続依存の経済学と移転価格透明性の経済学に関する作業は、両方が隠れた認識コストが、アイデンティティとルーティングがきれいに証明されていない場合にどのように交渉コストになるかを示しているため、関連性がある。
テストは古くなる。取引相手は変わる。プラットフォームはサポート境界を変更する。新しいワークロードが古いゲートウェイに接続する。二年前にポータビリティをテストした購入者はもはや生きたオプションを持っていないかもしれない。したがって、登録簿は、買収が署名されたとき、主要なサプライヤー条件が更新されたとき、規制対象の顧客がオンボードされたとき、またはセキュリティ証拠が実質的に変わったときにレビューされるべきである。作業は、継続的に行われる方が脅威の下で再構築されるよりも小さい。
結果は不快かもしれない。一部のワークロードは一定期間プラットフォーム依存であることが判明するだろう。それは失敗ではない。それは情報である。明示的に価格付けされた依存関係は、ゲートウェイ料金の内側に隠れた依存関係よりも安全である。
エンタープライズ内部にもガバナンス上の利益がある。パブリックアイデンティティがワークロードごとおよび出口オプションごとに測定されると、アーキテクチャチームはもはや回復力について抽象的に議論する必要がなくなる。それは調達にどの欠落した証明が更新レバレッジを生み出すかを示し、セキュリティにどの証拠が失われるかを示し、財務にどの譲歩が実際には移行コストであるかを示し、事業所有者にどの取引相手が移動を遅らせるかを示すことができる。その共有された見解は内部の非難を減らす。組織はクラウド出口をイデオロギーとして扱うのをやめ、それを所有者、日付、テストを持つ名前付き依存関係のセットとして扱い始める。
最終テストは調達、貸し手、主要顧客に属する
最終決定はアーキテクトだけに任せるべきではない。彼らはアプリケーションが他の場所で実行できるかどうかを会社に伝えることができる。調達、貸し手、主要顧客は、ビジネスアイデンティティが移動を生き延びられるかどうかをテストしなければならない。彼らの質問は異なり、より厳しい。なぜなら彼らは交渉力、継続性、責任に焦点を当てるからである。
調達は、サプライヤーがサービス品質のために保持されているのか、それとも購入者が認識されたパブリックアイデンティティを時間内に移動できないために保持されているのかを尋ねるべきである。答えがサービス品質である場合、更新はパフォーマンス、セキュリティ、価格で交渉できる。答えが閉じ込められたアイデンティティである場合、更新はその事実を開示し、移行サポートを購入し、依存関係を減らすための期限を設定すべきである。自らの価値に自信のあるサプライヤーは、購入者の蓄積されたアドレス記憶を保持の隠れた基盤として必要とすべきではない。
貸し手は、サプライヤー関係が悪化したり、買収がエステートを変更したり、プラットフォームアカウントが争われた場合に、収益に重要なワークロードが顧客へのサービスを継続できるかどうかを尋ねるであろう。答えは証拠を指すべきである：管理されたアイデンティティまたはマッピングされた置き換え、宛先の受け入れ、ルーティングとセキュリティのテスト、取引相手の移行記録、保持されたログ、割り当てられた所有者、オーバーラップウィンドウ、ロールバック。システムがクラウドネイティブであるという声明は貸し手の質問に答えない。クラウドネイティブのコンピュートでも、現在の代替案がないプラットフォーム管理のパブリックアイデンティティを通じて世界に面する可能性がある。
主要顧客は、承認された送信元アドレスが変更されるかどうか、セキュリティ属性が存続するか、移行がビジネスを中断させた場合のリスクを誰が負うかを尋ねるであろう。エンタープライズは、事前にセカンダリアイデンティティを交渉するか、オーバーラップ期間に合意するか、配信プラットフォームから独立したエンタープライズ保有範囲を認識するよう顧客を説得する必要があるかもしれない。それは単なるサプライヤーレバレッジではない。それは顧客自身の契約連鎖全体にわたる相関リスクを減らす。
委員会はポータビリティの芝居を拒否すべきである。顧客管理アドレスに言及する契約は、どの宛先もその範囲を受け入れていなければ弱い。ログをエクスポートする権利は、エクスポートが属性をサポートできなければ弱い。終了権は、パブリックアイデンティティが取引相手が変更できる前に消えれば弱い。レジストリ記録は、プラットフォームが受け入れを説明のない裁量として扱うなら弱い。すべての権利は、テスト、指名された所有者、レビュー日、救済策に対応すべきである。
ここが LACNIC 地域の証明層、プラットフォーム契約、購入者自身の運用規律が出会う場所である。LACNIC は保有者管理をポータブルかつ判読可能にすべきである。プラットフォームは受け入れ、拒否、証拠、移行サポートをレビュー可能にすべきである。エンタープライズは自身のアイデンティティを信頼できるものにする記録と取引相手を維持すべきである。NRS は保有者がそれらの期待を比較し防御するのを助けることができるが、購入者のデューデリジェンスを置き換えることはできない。
調達会議の終わりには、ゲートウェイ料金はまだスプレッドシート上にあるが、それはもはや決定を枠付けない。本当の質問は、配信が変更された場合に、どれだけの収益に重要なワークロードが信頼できるパブリックアイデンティティを維持できるか、どの証拠がそのオプションを行使可能にするか、古いパスが撤回される前に誰が行動しなければならないか、管理が失敗した場合の損失を誰が負うかである。コンピュートの移動はエンジニアリング能力である。パブリックアイデンティティの出口は交渉資産である。契約は、調達委員会、貸し手、主要顧客が必要になる前にその資産をテストできる場合にのみ健全である。
その最終テストは契約署名後に繰り返されるべきである。新しいエステートの最初の年は、チームがサービスを追加し、サプライヤーを接続し、顧客を承認し、次の層の外部記憶を作成する時期である。すべての新しいワークロードが最も簡単なプラットフォーム管理のパブリックエッジを継承する場合、購入者は新しいロゴの下で同じ依存関係を再構築する。重要なワークロードがエントリー時にアイデンティティの結果によって分類される場合、エンタープライズは、クラウドサービスが価値ある場所でそれらを使用しながら、選択肢を生かし続ける。目的は去ることではない。それは、ビジネスが知られるパブリックアイデンティティの静かな管理ではなく、サービスのメリット、貸し手の信頼、顧客の継続性によって守られる決定に留まることである。