概要

  • NetCore Bilişim は、トルコのシステムインテグレーション、クラウド、データセンター、バックアップ、マネージドサービス企業として理解するのが最適であり、その公開事業主張は、同じ Netcore という名称を使用する無関係なグローバルマーケティングテクノロジービジネスから区別されなければならない。
  • 同社は RIPE 記録上 AS211686 に関連付けられており、現在のルーティング情報源は、この ASN がもはや単なる休眠レジストリ遺物ではないことを示している：RIPEstat は2026年7月13日時点で AS211686 がアナウンスされていると報告し、そのクエリ時点で3つの可視の IPv4 /24を確認、一方他の BGP ビューではより広い5プレフィックスのフットプリントと混在した RPKI ステータスを示していた。
  • 有用なデューデリジェンスの問いは、NetCore Bilişim がレジストリ記録を持っているかどうかではない。それは、同社がルーティング、データセンター、バックアップ、アクセス、サポート、リカバリの行動を、トルコのエンタープライズおよび公共セクターのバイヤーが繰り返し発生するインシデント下で依存できるほど十分に観測可能にできるかどうかである。

企業境界はルーティングよりも重要である

NetCore Bilişim を読む際の最初のリスクはアイデンティティの漂流である。"Netcore"の検索結果は、すぐに Netcore Cloud という名称を使用する、より大規模で無関係なマーケティングテクノロジーベンダーと衝突する。その別のビジネスはカスタマーエンゲージメントソフトウェアを販売し、ソフトウェアレビューデータベースに登場し、非常に異なる製品表面を持つ。この記事のトルコ企業はNetCore Bilişim Hizmetleri A.Ş.であり、イスタンブールとアンカラに連絡先を持つトルコ拠点の IT サービス・インフラ企業で、トルコ語の運用ページ、RIPE NCC の組織記録、AS211686 へのディレクトリリンクを持つ。

その区別は表面的なものではない。クラウド、バックアップ、データセンター、コネクティビティサポートを求めるバイヤーは、名前だけで調査プロセスを進めると、誤った「Netcore」から信用を容易に取り込んでしまう可能性がある。このエンティティの公開証拠は、トルコ企業自身のページ、RIPE データベース記録、独立したルーティング観測者、パートナーおよび労働市場ページ、到達可能なサポート情報から組み立てられなければならない。それは、別の企業アイデンティティに属するカスタマーエンゲージメントソフトウェアのレビュー、グローバル SaaS ランキング、または消費者マーケティングのケーススタディから借用されるべきではない。

同社自身の説明は比較的現実に即している。英文のアバウトページには、NetCore IT Services は2009年に設立されたシステムインテグレーターであり、イスタンブール本社とアンカラ地域オフィスから顧客にサービスを提供していると記載されている。同ページは、販売およびアフターサポート、設置、保守、メーカーパートナーとのコンサルティングを提供すると述べている。また、NetCore はクラウドおよびデータサービスに投資しており、トルコのさまざまな地域でクラウドインフラおよびデータセンターサービスを提供し、サービスを NetCore IT Services、iCore Cloud、Core Telecom、NetCore Ankara の下にグループ化しているとしている。トルコ語のページでも同様の基本的なストーリーを提供しており、70名以上の従業員、1,000以上の完了プロジェクト、800以上の顧客体験を主張している。これらの数字は企業の主張であり、独立した監査済みのパフォーマンス証拠ではなく、商業的なシグナルとして有用である。

公開ディレクトリ記録は、より狭いネットワークインフラの視点から始まる。同社を自律システム番号 AS211686 にリンクし、エンティティを IP トランジットまたはキャリアネットワークプロバイダーとして位置づける。そのディレクトリの枠組みは、調査を観測可能なネットワークリソースへと導く点で価値がある。しかし、ディレクトリのテキストは「将来の BGP アクティベーション」と潜在的な影響についても述べている。現在の公開ルーティング証拠は、そのフレーズが示唆するよりも活発である。2026年7月13日、RIPEstat の AS 概要は AS211686 のホルダーを「netcore NETCORE BILISIM HIZMETLERI AS」と報告し、AS がアナウンスされているとマークした。そのルーティングステータスエンドポイントは、RIS フルフィードピア全体で IPv4 の可視性を示し、最終確認ルートは194.213.25.0/24で2026年7月13日であった。したがって、ディレクトリのリードはライブレジストリとルーティング証拠によって修正されなければならない：AS211686 は単なるデータベース内の休眠名ではない。

その修正は、この記事の問いを変える。ASN が観測可能であれば、問題はいつかアクティベーションがトルコのルーティングパスを導入するかどうかではなくなる。問題は、公開ルートセット、ルートオブジェクト、RPKI 状態、上流記録、サービス主張が、誰が何を運用しているのか、障害時に誰が責任を負うのか、クラウドおよびマネージドサービスの主張が実際のコントロールサーフェスにどのようにマッピングされるのかを顧客が理解するのに十分に首尾一貫しているかどうかである。

NetCore が販売するもの

NetCore の公開サービスページは、古典的なシステムインテグレーションとマネージドインフラの中間に位置するポートフォリオを説明している。同社は、保守サポート、専門家コンサルティング、設置、統合などのプロフェッショナルサービスをリストアップしている。また、サーバー管理、マネージドバックアップ、マネージドセキュリティ、ディザスタリカバリなどのマネージドサービスをリストアップしている。その企業 IT ページは、サーバーとデータストレージ、バックアップとアーカイブ、事業継続とディザスタリカバリ設計、仮想化、ローカルエリアネットワーク、ワイヤレスネットワーク、ネットワーク監視、セキュリティをカバーしている。データセンターとクラウドのページは、iCore 名の下で、仮想サーバー、インターネットおよび IP アクセス、クライアント to サイトおよびサイト to サイトアクセス、S3 ストレージ、CIFS/NFS ストレージ、専用ストレージ、バックアップストレージ、ディザスタリカバリ、ホスティング、ファイアウォールおよび WAF サービス、SIEM、SOC、ランサムウェア保護、コンテナプラットフォーム管理を宣伝している。

それは広い表面である。コンピューティング、ストレージ、ネットワークアクセス、セキュリティ監視、ディザスタリカバリ、ライセンス、リモート運用、フィールドサポートに触れている。また、実際の製品を単一のマシンやアプリケーションに絞り込むことを難しくしている。NetCore は、自己完結型のデータベースシステム、単一のクラウドアプライアンス、または狭い SaaS ツールを提示しているのではない。それは、統合労働、インフラ運用、ベンダー関係、データセンター容量、サポートワークフローのバンドルを提示している。そのため、技術的な問いは運用上のものにならざるを得ない：実際のサービスプレッシャーの下で作業が繰り返される場合に、顧客のシステムを最新、管理可能、クエリ可能、回復可能、安全に保つことができるか？

同社のバックアップ運用センターページはこれを明確にしている。ソフトウェアライセンス、ハードウェア容量、運用を中心としたバックアップマネージドサービス（BaaS）を説明している。運用上の主張には、24時間365日の運用、SLA ベースのレポート、24時間365日の監視、リモート接続、フィールド運用が含まれる。これらは簡単な約束ではない。バックアップサービスは、エージェントやジョブが完了し、障害が通知され、保持が適用され、オフサイトまたはクラウドストレージが使用可能で、テナント間でアクセス権が漏洩せず、復元テストが実行され、レポートが特定のワークロードを合意されたウィンドウ内で回復できることを証明するのに十分に詳細であるという、いくつかの目に見えないルーチンが順番に機能して初めて価値を持つ。公開ウェブページはこれらの言葉を言うことができる。特定の顧客に対してこの作業が行われていることを証明することはできない。

iCore クラウドカタログについても同様である。仮想サーバー、S3 ストレージ、バックアップストレージ、ディザスタリカバリ、ファイアウォール管理、SIEM 管理といった用語は、買い手がトルコのクラウドまたはマネージドインフラ提案で見ることを期待するものを説明している。しかし、それら自体ではアーキテクチャを示さない。テナント分離、ストレージ耐久性、物理データセンターの場所、バックアップ復元成功率、インシデント履歴、監視範囲、変更管理規律、クロスコネクト設計、DDoS 対策、上流の多様性を明らかにしない。また、NetCore がスタック全体を直接運用しているのか、自社スタッフとサプライヤーインフラ、コロケーションパートナー、メーカー支援サービスを組み合わせているのかも示さない。

その欠如は非難ではない。多くのインフラプロバイダーはアーキテクチャの詳細、顧客リスト、運用マニュアルを非公開にしている。ポイントはより狭い：買い手はサービスカタログをパフォーマンス証拠として扱うことはできない。公開ページは製品の意図と販売語彙を確立する。レジストリとルーティング記録はネットワークリソースの存在を確立する。パートナーと労働市場のページは市場での存在感を確立する。これらの情報源はいずれも、顧客固有の技術的デューデリジェンスパケットに取って代わるものではない。

クラウドの価値は証拠の連鎖に依存する

地域のインフラプロバイダーの中核となる商業的な約束は、通常、新規性ではない。それは調整の負担を軽減することである。顧客は、「仮想サーバー」や「S3 ストレージ」という言葉が珍しいからバックアップ、ストレージ、監視、アクセス作業をマネージドプロバイダーに移すのではない。第三者によるハードウェア調達、ライセンス、ネットワーク到達性、データセンターの存在、サポートスタッフ、定期的な運用チェックのバンドルが、断片化された内部スタックよりも監督しやすいサービスにまとめられる可能性があるから移すのである。NetCore の公開ページはまさにその市場に向けて語っている。メーカーパートナーシップ、データセンターとクラウド容量、マネージドバックアップ、セキュリティ運用、フィールド運用、地域サポートを組み合わせている。その組み合わせはトルコでは魅力的であり、特に現地の言葉、現地訪問、国内の調達とサポートの期待に精通したプロバイダーを必要とする買い手にとってはそうである。

しかし、同じバンドルは測定の問題を生み出す。サービスカタログは、統合が証明される前に多くのものが統合されているように見せることができる。顧客がある表面からクラウドコンピューティングを、別の表面からバックアップストレージを、さらに別の表面からファイアウォール管理を、そして AS211686 または関連するプロバイダーパスを通じてコネクティビティを購入する場合、弱点はサービスのカテゴリー間に存在する可能性がある。バックアップは完了しても、復元されたホストが意図したネットワークパスを通じて到達可能でないかもしれない。仮想サーバーは動作しても、顧客はスナップショットがどこに保存されているか、誰が管理プレーンにアクセスできるかを知らないかもしれない。ファイアウォールルールが変更されても、ルートポリシーが依然として予期しない上流を通じてトラフィックを送るかもしれない。サポートチームは迅速に対応しても、データセンターやトランジット依存関係に対する権限を持たないかもしれない。これらは抽象的なエッジケースではない。それらは、マネージドインフラが作業を削減するのか、それ単に顧客の建物の外に混乱を移すのかを決定する日常的な継ぎ目である。

したがって、NetCore の公開証拠は連鎖として読まれなければならない。公式ページは、同社がコンピューティング、ストレージ、バックアップ、ネットワーキング、セキュリティ、運用に触れるサービスを販売したいことを確立する。RIPE 記録は、関連するトルコの法人および LIR ID が存在し、AS211686 と NetCore 関連のアドレススペースを持つことを確立する。RIPEstat と BGP.he は、ASN が観測可能な IPv4 ルーティングを持つことを確立する。RPKI 検証は、RIPEstat で可視の現在の3つのプレフィックスが有効な発信元認証を持ち、一方最近確認された2つのプレフィックスが発信元 AS の疑問を提起したことを確立する。LinkedIn、Kariyer.net、Equinix は市場での存在感とパートナーコンテキストを確立する。その連鎖の各リンクは有用である。どのリンクも、単独では最終的な顧客アウトカムを証明しない。

そのため、最も価値のある買い手の質問は順次的である：サービスのどの部分が証拠連鎖のどの部分に依存するのか？サービスが顧客所有のハードウェアに対する専門的な設置と保守のみであれば、AS211686 は二次的かもしれない。サービスがホスト型仮想サーバー、クラウドバックアップ、顧客インターネットアクセス、またはディザスタリカバリフェイルオーバーを含む場合、AS211686 とその周辺のルートポリシーが重要になる。サービスがセキュリティ監視を含む場合、データ収集、アラートエスカレーション、ネットワーク可視性が重要になる。サービスがサイト to サイトアクセスを含む場合、プレフィックス所有権、上流の多様性、ルート変更管理が重要になる。NetCore はこれらの依存関係を、販売カテゴリーだけでなく、平易な運用用語で説明できるべきである。

ここで観測可能性が単なる技術的な好みを超える。買い手にとって、観測可能性とは、障害後に「何が変更されたのか、誰が変更したのか、何に影響したのか、修正されたことを示す証拠は何か？」に答えられる能力を意味する。クラウドおよびマネージドサービス契約では、その質問はログ、チケット、バックアップレポート、復元記録、ルート監視、認証イベント、データ配置記録、サポートコミュニケーションに及ぶ。公開情報源はこれらの成果物を示すことはできないが、プロバイダーの外部アイデンティティがそれらをサポートするのに十分に首尾一貫しているかどうかを明らかにすることはできる。NetCore の場合、外部アイデンティティは調査するには十分に首尾一貫しているが、プロバイダーの直接的な証拠なしに受け入れるにはまだ十分に透明ではない。

AS211686 は現在、観測可能な表面の一部となっている

AS211686 が重要なのは、NetCore のマーケティングコピーから独立して観測できるからである。RIPE データベースの aut-num オブジェクトは、as-name「netcore」と組織 ORG-NBHA1-RIPE を使用して AS211686 を識別する。RIPE 組織オブジェクトは NETCORE BILISIM HIZMETLERI AS という名前、国 TR、組織タイプ LIR、トルコ登録番号716341-0、ネットワーク連絡先情報を持つ。組織オブジェクトは2023年3月29日に作成され、2026年5月13日に最終更新された。aut-num オブジェクトは2023年4月3日に作成され、2026年1月7日に最終更新された。

これらの日付は、ルーティングアイデンティティを会社の最近の進化段階に位置づける点で重要である。NetCore 自身のトルコ語ページは、同社が2022年にクラウドおよびデータサービスに投資したと述べている。RIPE 組織と ASN 記録は2023年に続いた。RIPE inetnum 検索で194.213.25.0/24は、ネット名 TR-NETCORE-20240902、国 TR、組織 ORG-NBHA1-RIPE、ステータス ALLOCATED PA、作成日2024年9月2日、最終更新日2026年1月7日を示す。これは、トルコのクラウドまたはネットワークサービスの推進に関連するより新しい IP アドレスリソースを示唆しているが、顧客がアドレススペースをどのように使用するかを証明するものではない。

2026年7月13日の RIPEstat のルーティングステータスデータは、AS211686 が185.148.13.0/24で2021年3月に最初に確認され、194.213.25.0/24で7月13日のクエリ時に最後に確認されたことを示した。その応答では、すべての326の RIS フルフィードピアからの IPv4 可視性、ゼロの IPv6 可視性、3つの可視の IPv4 プレフィックス、768の IPv4 アドレスを報告した。低可視性ルートを除外した RIPEstat のアナウンスドプレフィックスエンドポイントは、7月13日まで延長される3つのプレフィックスを示した：185.15.199.0/24、185.95.1.0/24、194.213.25.0/24。また、188.132.166.0/24と188.132.167.0/24が2026年6月29日から7月7日まで存在し、そのデータセットでは7月7日08:00 UTC に終了したことを示した。

他の BGP 観測者は同じフットプリントを提示しなかった。Hurricane Electric の AS211686 用 BGP Toolkit ページは、5つの発信元かつアナウンスされた IPv4 プレフィックス、0の IPv6 プレフィックス、1,280のオリジネートされた IPv4 アドレス、2つの観測された IPv4 ピア、5つのアナウンスされたプレフィックスをリストした：185.15.199.0/24、185.95.1.0/24、188.132.166.0/24、188.132.167.0/24、194.213.25.0/24。IPinfo の AS ページは、名前 NETCORE BILISIM HIZMETLERI AS、国トルコ、ホスティング ASN タイプ、RIPE レジストリ、768の IPv4 アドレス、サマリーに IPv6 アドレスなしをリストし、ホストされているドメインと地理位置情報を記した。BGP.tools は AS211686 を2つのネットワークとピアリングし、2つの上流キャリアを持つ小さなネットワークと説明したが、ページはスクレイピング制御のために一部のデータが削除されたと警告した。

これらの違いは公開ルーティング研究では正常である。ルートコレクターは異なる視点、可視性しきい値、リフレッシュ時間、データプロダクトを使用する。しかし、違い自体が有用である。それらは、顧客が単一の「ASN ルックアップ」結果に依存すべきでない理由を示している。責任ある評価は、現在の BGP 可視性、RIPE DB aut-num ポリシー、ルートおよび inetnum オブジェクト、RPKI 発信元検証、上流契約、顧客向けサービス設計を比較するだろう。また、NetCore に、顧客に影響を与えるアナウンスについてどのソースを権威として扱うべきかを尋ねるだろう。

レジストリポリシーとライブルーティングは同じストーリーを語らない

AS211686 の RIPE aut-num オブジェクトは、AS15924、AS9121、AS34984、AS208972 のインポートおよびエクスポートポリシーラインをリストしている。これは登録された意図または管理ポリシーであり、ライブルーティング測定ではない。2026年7月12日にクエリされた RIPEstat のルーティング一貫性エンドポイントは、より微妙なビューを示した。そのクエリでは、AS208972 が BGP と whois の両方で見つかり、AS15830 が BGP でのみ見つかり（whois にはなし）、AS15924、AS9121、AS34984 が whois でのみ見つかった（BGP にはなし）。Hurricane Electric のページも同様に、ピア AS15830（Equinix (EMEA) Acquisition Enterprises B.V.）と AS208972（GIBIRNET Iletisim Hizmetleri Sanayi ve Ticaret Limited Sirketi）を観測した。IPinfo のページは対照的に、1つのピア/上流を AS15924（Vodafone Net Iletisim Hizmetler AS）と要約した。

正しい解釈は、単純な意味で一方のページが「間違っている」に違いないということではない。BGP 隣接性は時間に敏感である。いくつかのデータセットは、観測されたピアとは異なる上流を要約する。登録されたインポート/エクスポートポリシーは実際のピアリングに遅れをとる可能性がある。プロバイダーはトランジットを変更し、ルートサーバーを使用し、データセンター関係を通じてアナウンスし、または古いポリシーラインをそのままにしておく可能性がある。調達バイヤーにとって、運用上のメッセージは、NetCore の公開ピアリングとトランジットの状況が直接的な確認を必要とするということである。

これは商業的に重要である。なぜなら、NetCore のサービスカタログにはインターネットアクセス、IP サービス、クラウドサービス、データセンターサービス、ホスティング、セキュリティサービス、ディザスタリカバリが含まれているからである。ネットワークの多様性はこれらすべての約束の一部である。バックアップ運用は十分に人員が配置されていても、復元トラフィックが脆弱な上流パスに依存している場合、顧客を失敗させる可能性がある。プライベートクラウドは十分に仮想化されていても、ルート変更の管理が不十分であれば問題が発生する可能性がある。マネージドファイアウォールまたは WAF サービスは正しく設定されていても、ルート、DNS、データセンターの説明責任の連鎖が不明確であれば診断が難しくなる可能性がある。

したがって、登録された ASN は説明責任のハンドルとして機能する。これにより、顧客は具体的な質問をすることができる：顧客サービス用に NetCore が発信するプレフィックスはどれか？内部運用、パブリッククラウド、ホスティング、バックアップ、管理、監視、顧客アクセスに使用されるプレフィックスはどれか？契約している上流はどれで、ルートサーバーや一時的なパスを通じて観測されるだけのものはどれか？RIPE DB のポリシーラインのうち、現在有効なものはどれか？意図的に維持されているルートオブジェクトはどれで、レガシーなものはどれか？顧客向けルートのアナウンスまたは撤回の変更管理プロセスはどのようになっているか？ルートポリシーを変更する権限があるのは誰か？ルートリーク、ハイジャック、RPKI 無効、上流インシデントはどのようにエスカレーションされるか？

これらの質問は実用的である。顧客が事前に NetCore のプライベートアーキテクチャを知っている必要はない。NetCore がレジストリアイデンティティを、顧客が購入しているサービスと比較できる運用記録に変換する必要がある。

RPKI ステータスは証拠と保証の間の線を露呈する

RPKI は、AS211686 が単なるディレクトリエントリを超える場所の一つである。2026年7月13日の RIPEstat の RPKI 検証チェックは、185.15.199.0/24、185.95.1.0/24、194.213.25.0/24が発信元 AS211686 として有効であることを示した。これは肯定的なシグナルである：これら3つのプレフィックスについて、観測された発信元はクエリ時に公開されたルート発信元認証データと一致していた。

同じ RIPEstat チェックは、188.132.166.0/24と188.132.167.0/24が AS211686 に対して invalid_asn であることを示し、バリデートする ROA はこれらのプレフィックスの発信元を AS42910 と命名していた。RIPEstat のアナウンスドプレフィックスエンドポイントは、これら2つの/24が2026年6月29日から7月7日まで可視であったが、そのエンドポイントの7月13日の最新時刻では可視ではないことを示した。Hurricane Electric のページは、開かれたときにも5つの発信元プレフィックスの間にそれらをリストしていた。これにより慎重な読み取りが生まれる：最近の BGP 観測で2つの古い/24が可視であったという公開証拠があり、公開検証データは発信元 AS211686 がクエリ時にそれらのプレフィックスの ROA 発信元と一致しなかったと言っている。NetCore の説明なしに、悪意のあるルーティング、顧客への影響、またはアクティブなインシデントを証明するものではない。

インフラバイヤーにとって、これはデューデリジェンス項目である。RPKI 無効は、古い ROA、プロバイダー移行、委任リソース、ルート発信元の変更、またはルート認証のミスによって引き起こされる可能性がある。また、インターネット上のネットワークが無効なルートを拒否した場合、到達可能性の問題を引き起こす可能性がある。運用上の問題は、公開ページにレッドフラグが存在することではない。それは、NetCore が、顧客が到達可能性の障害として経験する前に、発信元検証の不一致を検出し、説明し、解消するための規律あるプロセスを持っているかどうかである。

同じ原則が RIPEstat のルーティング一貫性リストにも適用され、BGP にないいくつかの ARIN whois プレフィックスや、BGP で観測されなかった IPv6 /40エントリが含まれていた。そのようなエントリは、ルートオブジェクト、履歴データ、サードパーティ記録、またはコンテキストを必要とするルーティング認証表面を反映している可能性がある。それらはアクティブな NetCore サービスの証明ではない。しかし、同社のネットワークアイデンティティが、ワンラインの ASN エントリとして放置されるのではなく、生きたコントロールサーフェスとして文書化されるべき理由を示している。

RPKI は、同社のサービスページにセキュリティ、SOC、SIEM、ファイアウォール、WAF、ランサムウェア保護の文言が含まれているため、特に関連性が高い。セキュリティサービスはエンドポイントやログツールだけではない。クラウドアクセス、ホスト型ワークロード、ディザスタリカバリインフラを提供する企業にとって、ルート発信元の衛生はセキュリティ態勢の一部である。障害後にシステムを復元する顧客は、復元されたシステムが到達可能であることを必要とする。クラウドバックアップを使用する顧客は、本番環境からバックアップストレージへ、そしてバックアップストレージからリカバリターゲットへの予測可能なパスを必要とする。マネージドファイアウォールサービスに依存する顧客は、トラフィックが期待されるパスを通って到着することを必要とする。RPKI の有効性はこれらの結果を保証するものではないが、発信元検証の不一致はそれらを損なう可能性がある。

ここでの証拠はバランスの取れた結論を支持する。AS211686 は観測可能な現在のルーティングを持ち、現在 RIPEstat で可視の3つの/24に対して有効な RPKI を持ち、最近観測された2つの/24が AS211686 に対して無効とマークされたことに関する公開の疑問がある。これは NetCore を純粋に主張されたインフラプロバイダーから検査可能なネットワーク運用者へと移行させるのに十分である。クラウドサービスを回復力がある、マルチホーム、監査済み、ストレス下で顧客対応可能として認定するには十分ではない。

サービスカタログは実際には労働カタログである

NetCore のページはおなじみのインフラ用語を使用しているが、その商業的約束は人とプロセスに大きく依存している。「マネージドバックアップ」は箱ではない。それは、ジョブの監視、障害の修正、保持の調整、証拠の作成、復元のテスト、そして幹部が会社がランサムウェアイベントを生き残れるかどうか尋ねたときに顧客の質問に答えるという反復的な労働である。「ネットワーク監視と管理」はダッシュボードではない。それは、どのアラートが重要か、誰がそれらを所有するか、変更がどのように承認されるか、いつフィールドスタッフまたはリモートアクセスが使用されるかを決定する作業である。「データセンターとクラウドソリューション」は単なるラックや仮想 CPU ではない。それは、キャパシティプランニング、顧客オンボーディング、アクセス制御、メータリング、パッチ適用、データ配置、インシデント対応の作業である。

これがローカルサポートが重要な理由である。NetCore 自身のページはイスタンブール本社とアンカラ地域オフィスを強調している。その LinkedIn 企業ページは、トルコの IT サービスプロファイル、非公開企業分類、2009年設立日、イスタンブール Ataşehir 本社、51-200人の従業員規模帯、バックアップ、データ保護、クラウド移行、システムインテグレーションに関する公開投稿を示している。Kariyer.net のプロフィールはシステムインテグレーターのポジショニングを繰り返し、過去の Interpromedya ランキングの変動を説明している。Equinix のパートナーディレクトリは、クラウドサービスプロバイダー、マネージドサービスプロバイダー、バックアップ知識、ハードウェア、ソフトウェア、仮想化にわたるシステムインテグレーションソリューションを含む会社のハイライトで NETCORE BİLİŞİM HİZ. A.Ş.をリストしている。

これらは、同社の役割を三角測量するため、有用な市場シグナルである。NetCore は単なる ASN ホルダーではない。それは、インテグレーター、マネージドサービスプロバイダー、バックアップおよびクラウドサービスのベンダー、より大きなデータセンターエコシステムのパートナー、トルコの IT サービス市場における雇用主として可視である。シグナルは顧客の成果を証明しないが、サービスストーリーを素のレジストリ記録よりも信憑性のあるものにする。

また、監督コストをより明確にする。NetCore のインフラサービスを採用する顧客は、単により低いストレージやコンピューティングコストを購入しているわけではない。顧客は運用責任をサードパーティのサービス関係に移している。これにより、新しい作業が生まれる：契約レビュー、データ分類マッピング、アイデンティティとアクセスガバナンス、バックアップポリシー定義、復元テスト、ルートと DNS の文書化、インシデントコンタクト訓練、サービスレポート、コスト監視、終了計画。これらのタスクに人員が配置されていない場合、マネージドサービスは負荷の軽減ではなく、隠れた依存関係になる可能性がある。

そのようなプロバイダーにとっての商業的な問いは、ストレージ、コンピューティング、移行、ロックイン、データ品質の労働が顧客の現在のスタックを上回るかどうかである。NetCore にとって、答えはカタログから推測することはできない。それは顧客の既存の環境に依存する。アドホックなバックアップ、復元テストなし、ネットワークスタッフなしの小規模企業は、マネージドバックアップ、監視、フィールドサポートを提供できるローカルプロバイダーから利益を得るかもしれない。成熟した内部プラットフォーム運用を持つ規制対象企業は、はるかに多くの証拠を必要とするかもしれない：監査レポート、データ配置保証、RTO/RPO 証明、インシデント履歴、ルート発信元制御、サポートスタッフ、データ処理条件、終了ツール。公共セクターのバイヤーは、華やかなクラウド言語よりも、調達チャネル、ローカルサポート、文書化された説明責任が揃っているかどうかを気にするかもしれない。

そのため、NetCore は運用パートナーとして評価されるべきである。そのウェブサイトはバイヤーにどのサービスカテゴリーを販売したいかを伝える。その AS と RIPE 記録はバイヤーにネットワークアイデンティティの一部がどこにあるかを伝える。そのパートナーと労働市場のページはバイヤーに可視のローカルフットプリントがあることを伝える。欠けている橋は、顧客固有の運用証明である。

顧客が NetCore に維持するよう求めるべき運用記録

NetCore が不確実性を減らすための最もクリーンな方法は、インフラ顧客向けのコンパクトな運用記録を公開または提供することである。その記録は、機密の顧客名や内部図面を露出する必要はない。それは、同社がレジストリアイデンティティ、ルート可視性、サポート責任、サービス主張を1つの管理されたナラティブに結びつけることができることを示す必要がある。出発点はルートレジスターである：AS211686、現在のプレフィックス、各プレフィックスの意図された使用、アクティブな上流、ルートオブジェクトステータス、ROA ステータス、最終レビュー日、指名された運用オーナー。公開コレクターが一致しない場合、レジスターは NetCore がどの情報源を権威として扱い、その理由を説明すべきである。

2番目の要素はサービス対リソースマップである。プレフィックスがクラウド管理、顧客仮想サーバー、バックアップストレージ、監視、インターネットアクセス、テストインフラ、またはレガシートラフィックにサービスを提供する場合、正確なテナント詳細が非公開のままでも、顧客はカテゴリーを知るべきである。プレフィックスが顧客向けでない場合も、明確にすべきである。これにより、バイヤーが可視のルートを本番依存関係と誤認するリスクが減り、重要な本番ルートが無害なレジストリ詳細として扱われる逆のリスクも減る。

3番目の要素はリカバリ証明の形式である。NetCore のバックアップ運用ページは、サービスに24時間365日の運用、SLA ベースのレポート、監視、リモート接続、フィールド運用が含まれると述べている。バイヤーは月次レポートに実際に何が含まれているかを尋ねるべきである。それには、失敗したジョブ、修正されたジョブ、見逃されたウィンドウ、成功した復元テスト、ストレージ消費、暗号化ステータス、保持例外、チケット履歴が含まれているか？バックアップ完了と復元準備状態を区別しているか？誰がいつ障害を確認したかを示しているか？別の顧客のデータを露出せずにサンプルレポートを示すことができるプロバイダーは、サービスの名前だけを繰り返すプロバイダーよりもはるかに信頼しやすい。

4番目の要素はアクセスと権限モデルである。マネージドインフラは、プロバイダーの許可と顧客の許可の境界でしばしば失敗する。顧客は、誰がリモートセッションを開くことができるか、誰がバックアップポリシーを変更できるか、誰がファイアウォールルールを変更できるか、誰がルートポリシーに触れることができるか、誰がストレージにアクセスできるか、誰が緊急変更を承認するか、特権アクションがどのようにログ記録されるかを知るべきである。NetCore の公開ページは機密性、責任、サポートを強調している。それらの価値の運用バージョンは、監査や紛争を生き残ることができるアクセスモデルである。

5番目の要素はインシデント説明責任経路である。ネットワークまたはクラウドサービスにとって、最もコストのかかる分は、多くの場合、混乱が始まった後の最初の数分である。ルートが消失した場合、復元が失敗した場合、仮想ホストが到達不能になった場合、ファイアウォールポリシーが本番トラフィックをブロックした場合、ストレージプラットフォームが予期せず満杯になった場合、顧客はどのキューがケースを所有し、いつエスカレーションされるかを知る必要がある。その経路は技術カテゴリーを横断すべきである。「ネットワーク」、「バックアップ」、「セキュリティ」、「クラウド」は内部チームまたはベンダーラベルかもしれないが、顧客はそれらを1つの障害として経験する。NetCore の価値は、それらのラベルを顧客自身のチームよりも速く調整できる場合に高まる。

これらの成果物は NetCore 自身にも役立つだろう。それらは同社の現在の公開の曖昧さを説明しやすくするだろう。AS211686 の可視ルートセットは、正式な顧客保証プロセスの一部として監視できる。RPKI の不一致は、レガシー、移行中、是正済み、または顧客に影響を与えるものとして文書化できる。パートナー関係は、一般的な信用シグナルとして放置されるのではなく、コンテキストに配置できる。結果は、NetCore が直接運用するもの、再販するもの、統合するもの、ベンダーまたはデータセンターパートナーを通じてサポートするものの間のより明確な分割になるだろう。

バイヤーがプライベートアクセスなしで検証できること

実用的なデューデリジェンスプロセスは、公開証拠のみから完全に開始できる。第一に、アイデンティティを確認する。トルコの NetCore Bilişim ウェブサイト、RIPE 組織オブジェクト、LinkedIn ページ、Kariyer.net ページ、Equinix パートナーエントリはすべて同じ企業境界を指すべきである。無関係な Netcore Cloud マーケティングテクノロジーベンダーの結果は、NetCore Bilişim 自身が関係を文書化しない限り除外されるべきであり、ここで調査した情報源はそれを示していなかった。

第二に、ネットワークハンドルを確認する。AS211686 は RIPE DB、RIPEstat、BGP.he、IPinfo、およびバイヤーが好むルートコレクターでチェックされるべきである。観測されたルーティングは変更される可能性があるため、バイヤーはクエリ日を記録すべきである。2026年7月13日の公開チェックは、RIPEstat のルーティングステータス応答で現在の IPv4 可視性と IPv6 可視性なしを支持した。また、完全なプレフィックス数とピアセットに関するデータソースの不一致を示した。その不一致は珍しくないが、顧客が ASN を中心に本番アクセスを設計する前に、プロバイダーへの直接的な質問を引き起こすべきである。

第三に、RPKI とルートオブジェクトを検証する。ここで実行されたチェックでは、現在 RIPEstat で可視の3つの/24は AS211686 に対して有効であった。最近観測された2つの188.132.166.0/24と188.132.167.0/24のプレフィックスは、RIPEstat 検証で AS211686 に対して invalid_asn であった。バイヤーは、これら2つのプレフィックスが依然としてアナウンスされる予定か、顧客トラフィックがそれらに依存しているか、AS42910 が認証パスで期待されているか、どのような是正または説明が存在するかを尋ねるべきである。答えが「レガシーであり、もはや使用されていない」であれば、それは文書化されるべきである。答えが「顧客向け」であれば、顧客はルート発信元計画を必要とする。

第四に、サービスを証拠にマッピングする。提案がバックアップの場合は、ジョブ成功レポート、復元テスト証拠、保持構成、暗号化境界、サポートエスカレーション、リカバリラン…