Zusammenfassung
- PT Media Cloud Indonesia hat stärkere öffentliche Betriebsnachweise als viele kleine Hoster: Die APNIC/IDNIC-Registrierungen verbinden es mit AS140449, 103.152.240.0/23 und 2406:38c0::/32, während RIPEstat während des Überprüfungsfensters im Juli 2026 die von AS140449 angekündigten 103.152.240.0/24, 103.152.241.0/24 und 2406:38c0::/32 beobachtet hat.
- Das Unternehmen vermarktet ein breites Portfolio unter der Marke Media Cloud: Domains, WordPress- und Sitejet-Hosting, Indonesian VPS, SSL, professionelle E-Mail, Webdienste, Spiele-Hosting-Werbung und ein lokales Loop-Angebot auf mci.net.id, das dedizierte Bandbreitenpakete mit 1 Gbit/s, 2 Gbit/s und 3 Gbit/s anbietet.
- Die Bedenken hinsichtlich der Widerstandsfähigkeit sind ebenso konkret. PeeringDB listet einen Exchange-Anschluss an OpenIXP/NiCE und null Standorte für das Netzwerk; die RIPEstat-Nachbarschaftsdaten werden von AS138840 dominiert, und das RADB-IPv6-Routenobjekt beschreibt eine per Proxyservierung registrierte HSP Global-Kundenroute. Dies sind sichtbare Interkonnektivitätsnachweise, kein Nachweis unabhängiger Multi-Site-Kapazität.
- Die Nutzungsbedingungen und die Rückerstattungsrichtlinie von Media Cloud machen den physischen Fehlerpfad sichtbar: Dienste können aufgrund von Gerätestörungen, Wartung, Reparatur oder Austausch, Telekommunikationsunterbrechungen, Angriffen, Überlastung oder anderen Fehlern unzugänglich werden; die Rückerstattung für Internetdienste ist an mehr als sieben aufeinanderfolgende Tage Unterbrechung oder die Unmöglichkeit, den Dienst fortzusetzen, geknüpft.
- Das Beweislevel ist Mittel. Die Identität, die Produktoberfläche, der geroutete Adressraum und die derzeitige Zugänglichkeit sind gut belegt; die öffentlichen Nachweise zum Standort der Einrichtungen, zur Reservekapazität, zur Transitdiversität, zum getesteten Wiederherstellungsprozess und zu den Grenzen der Datenportabilität bleiben unvollständig.
Das Unternehmen ist sichtbar, aber die Abhängigkeit bleibt physisch
PT Media Cloud Indonesia verdient eine genauere Betrachtung als nur ein Etikett "kleiner Hoster". Das Unternehmen präsentiert zwei zusammenhängende öffentliche Oberflächen. Eine ist die konnektivitätsorientierte Websitemci.net.id, die lokale Loop- und FTTH-Konnektivitätslösungen bewirbt und die Benutzer zum Cloud-Dienstleistungsshop führt. Die andere istmediacloud.id, die kundenorientierte kommerzielle Oberfläche für Domains, Hosting, VPS, SSL-Zertifikate, E-Mail und Webdienste. Diese beiden Oberflächen sind keine bloßen Marken-Anekdoten. Sie zeigen, dass das Unternehmen die Kunden bittet, ihm sowohl ihre grundlegende Internetpräsenz als auch strukturbildende Infrastrukturdienste anzuvertrauen.
Diese Zuversicht stößt auf sehr reale Einschränkungen. Ein VPS ist eine virtuelle Maschine, läuft aber auf physischer Rechenleistung, Speicher, Stromversorgung und Kühlung. "Unbegrenzte Bandbreite" ist ein Marketingbegriff, aber die Pakete durchlaufen immer noch Ports, Router, Filter, Glasfaser, Transitverträge und Exchange-Fabrics. Ein "24/7-Support"-Versprechen ist nur nützlich, wenn der Kunde das Team erreichen kann, selbst wenn der betroffene Dienst, das Ticketsystem, das DNS oder der Abrechnungsstatus ausgefallen ist.
Das lokale Loop-Angebot ist noch direkter: Es hängt vom letzten Meilen-Zugang, einem Interkonnektionspunkt, einem Upstream-Pfad, Bereitschaftstechnikern und einer Geschäftsregel ab, was passiert, wenn die Leitung außer Betrieb bleibt.
Die öffentlichen Nachweise beginnen auf der Ebene der digitalen Ressourcen. Der RDAP-Eintrag von APNIC/IDNIC fürAS140449listet MEDIACLOUD-AS-ID, PT Media Cloud Indonesia, "Internetdienstanbieter" und eine Verwaltungsadresse in Süd-Jakarta auf. APNIC/IDNIC zeigt auch das IPv4-Netzwerk103.152.240.0/23und das IPv6-Netzwerk2406:38c0::/32unter dem Namen MEDIACLOUD-ID. Diese Einträge beweisen nicht den Standort jedes Servers, aber sie sind weitaus solider als eine anonyme Reseller-Seite. Sie zeigen ein Unternehmen mit direkt sichtbaren digitalen Internetressourcen.
Das Unternehmen hostet auch seine öffentlichen Websites innerhalb dieses Fußabdrucks. Eine DNS-Überprüfung während dieser Recherche ergab, dass mci.net.id und mediacloud.id auf die Adresse 103.152.240.97 innerhalb der Zuteilung 103.152.240.0/23 aufgelöst wurden. Dies ist ein bescheidenes, aber wichtiges Signal: Die öffentliche Website wird nicht einfach hinter einem globalen Gateway gehostet, das nicht offensichtlich mit der Netzwerkregistrierung verbunden ist. Die Marke, die ASN und der geroutete Adressraum sind ausreichend aufeinander abgestimmt, um den Infrastrukturanspruch überprüfbar zu machen.
Der schwierige Teil besteht nicht darin zu beweisen, dass Media Cloud eine öffentliche Präsenz hat. Der schwierige Teil besteht darin, das Maß an Kundenresilienz zu bestimmen, das diese Präsenz mit sich bringt. Öffentliche Routing-Nachweise können zeigen, welche Präfixe sichtbar sind, welche ASNs dem Netzwerk benachbart sind, ob die Routenursprungsdaten abgedeckt sind und ob ein freiwilliges Exchange-Verzeichnis einen Port auflistet. Sie können nicht den Ersatzserver im Rack, den Einrichtungsvertrag, den Kunden-Backup-Prozess oder die Person, die befugt ist, die Hardware nach Mitternacht zu ersetzen, zeigen.
Diese Lücke steht im Kern des Artikels.
Das angekündigte Produktangebot geht über eine einfache VPS-Seite hinaus
Die Produktseiten von Media Cloud zeigen ein Unternehmen, das eine Komplettlösung für indonesische Kunden sein möchte, die eine Webpräsenz aufbauen wollen. DerMedia Cloud Shopgibt an, Domains, Hosting, einen Website-Builder, E-Mail, SSL-Zertifikate und VPS-Dienste bereitzustellen. Er bewirbt.id- und.com-Domains, Reseller- und Großhandelsdienste und ein Kästchen "Best VPS Cloud Hosting", das auf das VPS-Produkt verweist. Dies ist von Bedeutung, da ein breites Angebot mehrere Abhängigkeitspfade schafft. Ein Kunde kann eine Domain, DNS, ein SSL-Zertifikat, eine E-Mail-Mailbox, einen Website-Builder und einen VPS vom selben Anbieter kaufen und bei einem Vorfall feststellen, dass die technische Abhängigkeit und die Kontoabhängigkeit eng miteinander verbunden sind.
DieVPS-Seiteist der klarste Anspruch auf gehostete Kapazität. Sie bewirbt "VPS Indonesia", beschreibt den Dienst als "schnellen und stabilen indonesischen VPS zu erschwinglichen Preisen" und listet 100 % dedizierte Ressourcen, NVMe-Speicher, unbegrenzte Bandbreite und DDoS-Schutz auf. Sie gibt auch an, dass Kunden Betriebssysteme und vorkonfigurierte Anwendungen wählen können. Dies ist genau die Sprache, die ein kleines Netzwerk in eine geschäftliche Abhängigkeit verwandelt: Kunden kaufen nicht nur Adressraum; sie erwarten Rechenleistung, Speicher, Softwareinstallationen, Sicherheitskontrollen und ausreichende Netzwerkkapazität, um Anwendungen zugänglich zu halten.
Die Hosting-Seiten fügen eine weitere Ebene hinzu. DasSitejet-Hostingpräsentiert gebündeltes Hosting mit einem Website-Builder und hebt DDoS-Schutz, cPanel, Softaculous und One-Click-Installationen hervor. DasWordPress-Hostingverwendet dieselbe Sprache der Zuverlässigkeit und Funktionen, obwohl die Preistabelle zum Zeitpunkt der Abfrage für die erkannte Währung nicht verfügbar war. Dies ist nützlich, da es die zugrunde liegenden Plattformannahmen für das Kundenerlebnis offenlegt. cPanel, Softaculous, Website-Builder und WordPress-Hosting sind alle von Steuerungspanels, Lizenzstatus, Speicher und Backup-Praktiken abhängig. Dies sind operative Systeme, keine statischen Produktnamen.
E-Mail erweitert die Abhängigkeit weiter. DasE-Mail-Hostingbewirbt geschäftliche E-Mail mit einer Verfügbarkeitsgarantie von 99,9 %, benutzerdefinierten Domains, Sicherheit, Überwachung, 24/7-Support und Hilfe bei Einrichtung, Migration und Fehlerbehebung. DieProfessionelle E-Mailbeschreibt 8 GB pro Postfach, Webmail, Anti-Spam, Anti-Virus, DKIM-Signaturen, automatische Backups, E-Mail-Tracking-Funktionen und Audit-Logs. Die MX-Einträge bieten eine Nuance: mci.net.id verwendet Microsoft-E-Mail-Schutz, während mediacloud.id auf die Google-Mail-Server aspmx verweist. Dies ist nicht widersprüchlich; es zeigt, dass einige Teile des Unternehmens auf externe E-Mail-Plattformen angewiesen sind, auch wenn die öffentlichen Websites im eigenen Adressraum von Media Cloud liegen.
DieSSL-Seiteund die Domain-Seiten vervollständigen das Bild. Media Cloud verkauft Vertrauensebenen über den Servern: Domain-Registrierung, Transfer,.id-Identität, Zertifikate, Website-Erstellung und Postfachidentität. Ein Kunde, der diese Dienste bündelt, kann Bequemlichkeit gewinnen, schafft aber auch ein Wiederherstellungsproblem. Wenn die Abrechnung, die Identitätsprüfung, der Support oder das Steuerungspanel blockieren, können mehrere unabhängige Geschäftsfunktionen gleichzeitig blockieren.
Die Preisgestaltung der lokalen Loop macht die Frage nach Rack und Routing explizit
Die Startseite von mci.net.id ist ungewöhnlich nützlich, da sie nicht nur abstrakte Cloud-Dienste bewirbt. Sie wirbt für "lokale Loop- und FTTH-Konnektivitätslösungen" und beschreibt eine "dedizierte Hochgeschwindigkeitsbandbreite für zuverlässige Geschäftskommunikation". Die Seite listet Loop-Pakete zu 10.000.000 IDR pro Monat für 1 Gbit/s, 20.000.000 IDR pro Monat für 2 Gbit/s und 30.000.000 IDR pro Monat für 3 Gbit/s mit Links "Angebot anfordern" auf. Sie gibt auch an, dass Media Cloud sichere und leistungsstarke dedizierte Konnektivität, geringe Latenz, skalierbare Integration und lokalen 24/7-Support bietet.
Diese Behauptungen sind nicht gleichbedeutend mit einer öffentlichen Offenlegung der Einrichtung. Sie verlagern jedoch die Analyse vom einfachen Webhosting auf die physische Infrastruktur. Ein lokaler Loop-Dienst benötigt einen Kunden-Zugangspfad, einen Interkonnektionspunkt, einen Link-Pfad, einen Router, ein Support-Modell und einen Reparaturprozess. Der Fehlerpfad ist nicht mehr einfach "der VPS ist ausgefallen".
Es könnte sich um ein Problem mit der Glasfaser der letzten Meile, ein Problem mit dem Upstream-Anbieter, ein Problem mit dem Zugangsrouter, ein Problem mit der Interkonnektion im Rechenzentrum, ein Problem mit der Support-Dispatch, eine Blockade der Abrechnung oder ein Problem mit der kundenseitigen Ausrüstung handeln, das der Anbieter möglicherweise kontrollieren kann oder nicht.
Auch die Geschichte der öffentlichen Adresse erfordert Vorsicht. Die APNIC/IDNIC-Registrierungen der digitalen Ressourcen geben eine Adresse im Prudential Center in Süd-Jakarta an. Die aktuellen öffentlichen Fußzeilen von Media Cloud leiten die Leser zum Epicentrum Walk, 3. Stock, Einheit A306-307, Jl. HR Rasuna Said, Kuningan, Süd-Jakarta. Beide können auf unterschiedliche Weise wahr sein: Die eine kann eine Registeradresse sein, die andere ein aktuelles Büro oder ein Support-Standort, und keine identifiziert notwendigerweise den Ort, an dem die Arbeitslasten oder Router der Kunden tatsächlich gehostet werden.
Die Unterscheidung ist wichtig, da Kunden oft eine geschäftliche Kontaktadresse mit einer Installationsadresse verwechseln. Das sollten sie nicht.
Die lokale Loop-Seite nennt kein Rechenzentrum, kein Exchange-Gebäude, keinen Glasfaserpfad, keine Upstream-Transitanbieter, keine Servicegrenze und keinen Wiederherstellungsstandort. Dies ist für eine öffentliche Marketingseite normal, bedeutet aber, dass der Käufer nachfragen muss. Wenn der angebotene lokale Loop im selben Gebäude endet wie die gehostete Arbeitslast, unterscheidet sich das Fehlermodell von einem Loop, der in einem separaten Telekom-Hotel endet. Wenn der Loop von einem Partner bereitgestellt wird, können der Rückerstattungs- und Eskalationspfad von der Ticket-Warteschlange des Partners abhängen.
Wenn der Kunde Routing-Diversität benötigt, muss er wissen, ob zwei Stromkreise sich Kabelkanäle, Gebäudeeingänge, Patchfelder oder ein einzelnes Upstream-Gateway teilen.
Dies soll nicht sagen, dass das lokale Loop-Angebot von Media Cloud schwach ist. Es soll betonen, dass es die physische Abhängigkeit unvermeidbar macht. Die gehostete Kapazität erscheint elastisch, bis die letzte Meile oder der Upstream-Pfad ausfällt. Ein Kunde, der Cloud und lokale Konnektivität vom selben Anbieter kauft, sollte sich fragen, ob diese Bündelung die Kontrolle erhöht oder einfach den Fehler konzentriert.
AS140449 kündigt derzeit einen kleinen konsistenten Satz von Präfixen an
Die Routing-Nachweise sind klarer als die Nachweise für den Unternehmensstandort. DerRIPEstat AS140449-Überblickidentifizierte den Inhaber als "MEDIACLOUD-AS-ID – PT Media Cloud Indonesia" und zeigte, dass die AS während der Überprüfung im Juli 2026 angekündigt wurde. DieRIPEstat-Ansicht der angekündigten Präfixelistete 103.152.240.0/24, 103.152.241.0/24 und 2406:38c0::/32 als im Zeitfenster vom 27.06.2026 bis 11.07.2026 sichtbar auf. Dies bedeutet, dass die registrierte /23 operationell in zwei sichtbare IPv4-/24-Ankündigungen aufgeteilt ist, während die IPv6-Zuteilung als /32 angekündigt wird.
Diese Konfiguration ist mit einem kleinen Betreiber und nicht mit einer Hyperscale-Cloud konsistent. Zwei /24 bieten eine sichtbare öffentliche Präsenz, ausreichend für Websites, Shared Hosting, VPS-Adressen, Steuerungssysteme oder lokale Dienste, aber keinen massiven Retail-Cloud-Footprint. Das IPv6-/32 ist in Bezug auf die Adressen viel größer, aber das Volumen der IPv6-Adressen sollte nicht mit der installierten Rechenkapazität verwechselt werden.
Die Frage der nutzbaren Kapazität ist nicht die Anzahl der vorhandenen Adressen, sondern die Anzahl der Arbeitslasten, die im Fehlerfall gehostet, verschoben, wiederhergestellt und unterstützt werden können.
DerRouting-Verlaufvon RIPEstat fügt Kontinuität hinzu. Die beiden IPv4-/24 sind seit September 2020 im Verlauf sichtbar, während das IPv6-/32 seit März 2021 sichtbar ist. Im letzten beobachteten Intervall waren die IPv4-Präfixe bis zum 11.07.2026 noch sichtbar, und die IPv6-Route war ebenfalls bis zum 11.07.2026 sichtbar. Dies ist solider als eine neu erstellte, ruhende ASN. Es deutet auf eine öffentliche Routing-Oberfläche hin, die über Jahre hinweg bestanden hat.
Aber der Verlauf umfasst auch Zeiträume geringerer Sichtbarkeit. Öffentliche Route Collectors können zeigen, dass sich die Sichtbarkeit geändert hat; sie können nicht erklären, warum. Ein Rückgang kann eine Routing-Richtlinie, eine Collector-Abdeckung, ein Upstream-Problem, einen Wartungszeitraum, ein Routing-Filterung, RPKI- oder IRR-Effekte anderswo oder eine tatsächliche Dienstunterbrechung widerspiegeln. Es wäre unverantwortlich, den Verlauf in eine Behauptung einer bestimmten Unterbrechung umzuwandeln, ohne Betreiber- oder Kundenbelege.
Sein Wert ist enger: Er zeigt, dass der öffentliche Route-Edge ausreichend beobachtbar ist, um überwacht zu werden, und dass Kunden fragen können, was sich geändert hat, als sich die Sichtbarkeit änderte.
Der aktuelle BGP-Status ist ebenfalls aufschlussreich. DieBGP-Statusantwortvon RIPEstat zeigte viele globale Collector-Pfade zu den Media-Cloud-Präfixen, wobei die meisten Pfade AS140449 über AS138840 erreichten. Andere Pfade in der Stichprobe umfassten größere globale Transitnamen weiter oben, aber die wiederholte unmittelbare Nachbarschaft zu AS138840 ist die Abhängigkeit, die zählt. Ein Kunde benötigt nicht alle Details des Route-Collectors; er muss wissen, ob der Edge von Media Cloud einen Verlust oder eine Überlastung des unmittelbaren Upstream-Pfades überleben kann.
Die sichtbare Upstream-Geschichte verweist auf HSPnet und OpenIXP/NiCE
DieASN-Nachbarschaftsansichtvon RIPEstat verzeichnete drei benachbarte ASNs bei der Überprüfung am 11.07.2026: AS138840 als dominanten linken Nachbarn, AS7717 als weiteren linken Nachbarn und AS149004 als rechten Nachbarn. APNIC identifiziertAS138840als einen indonesischen NAP-Eintrag, der PT Parsaoran Global Datatrans / HSPnet zugeordnet ist. APNIC identifiziertAS7717als OpenIXP-AS-ID-AP. APNIC identifiziertAS149004als Morapido Net in Timor-Leste. Diese Etiketten beweisen keine Verträge, aber sie helfen, die Routing-Nachbarschaft zu erklären.
PeeringDB fügt eine freiwillige Interkonnektionsansicht hinzu. SeineNetzwerk-API-Abfrage für AS140449listet "PT Media Cloud Indonesia", Alias "Mediacloud", Websitehttps://mci.net.id, Info-Typ "Unternehmen", IPv6-Unterstützung, eine allgemein offene Richtlinie, eine IX-Anzahl von 1 und eine Standortanzahl von 0. Die zugehörigenetixlan-Abfragelistet OpenIXP/NiCE, einen 1-Gbit/s-Port, IPv4-Adresse 43.252.146.141, IPv6-Adresse 2001:7fa:f::457 und einen operativen Status. Dienetfac-Abfragegibt keinen Standorteintrag zurück.
Die stärkste Lesart ist praktisch: Media Cloud hat einen sichtbaren Exchange-Anschluss bei OpenIXP/NiCE und eine öffentliche Routing-Nachbarschaft, bei der AS138840 der von den Collectoren gesehene Hauptpfad ist. Die schwächste Lesart wäre, aus diesen Feldern eine vollständige Resilienzarchitektur abzuleiten. PeeringDB wird vom Betreiber gepflegt und ist freiwillig. Ein 1-Gbit/s-Exchange-Port beweist nicht, dass der gesamte Kundenverkehr im Falle eines Transitproblems über den Exchange laufen kann.
Eine Standortanzahl von 0 beweist nicht, dass das Unternehmen keine Racks hat; es bedeutet lediglich, dass PeeringDB keinen Standorteintrag für das Netzwerk auflistet. Eine beobachtete Upstream-Nachbarschaft beweist nicht, ob eine Verbindung Transit, Peering, Backup oder ein Routenserver-Pfad ist, es sei denn, sie wird durch Betreiberdokumentation gestützt.
Die RADB-Routenobjekte verstärken dieselbe Vorsicht. Eine RADB-Abfrage für AS140449 gab Routenobjekte für 103.152.240.0/24 und 103.152.241.0/24 mit Ursprung AS140449 und Beschreibungen, die PT Media Cloud Indonesia nennen, zurück. Das route6-Objekt für 2406:38c0::/32 verwendete den Ursprung AS140449, aber die Anmerkungen beschrieben ein per Proxy registriertes Routenobjekt für eine HSP Global-Kundenroute, die unter der Ursprungs-AS von Media Cloud exportiert wird, verwaltet von MAINT-AS138840.
Diese Formulierung macht die Frage des Anbietervertrags zentral: Wenn die IPv6-Route von HSP abhängt, um das Routenobjekt oder die Upstream-Vereinbarung zu verwalten, müssen die Kunden wissen, wer die Entität reparieren kann, wer Filter ändern kann und was passiert, wenn der Upstream-Vertrag oder der Support-Kanal ausfällt.
Die Ursprungsversicherung der Route bleibt unvollständig
Die Routenursprungsvalidierung ist kein vollständiger Resilienztest, aber eine bedeutende Prüfung. Sie überprüft, ob eine veröffentlichte Routenursprungsautorisierung (ROA) ein gegebenes Präfix und eine Ursprungs-AS unterstützt. Bei den RIPEstat-Überprüfungen im Juli 2026 gaben103.152.240.0/24,103.152.241.0/24und2406:38c0::/32"unbekannt" zurück, ohne validierende ROA in der überprüften Ansicht. RADB zeigte auch einen RPKI-Ursprungsvalidierungsstatus von "not_found" für die Routenobjekte.
"Unbekannt" ist nicht dasselbe wie "ungültig". Es bedeutet, dass die überprüften Routenursprungsvalidierungsdaten keine autorisierende ROA gefunden haben. Das praktische Risiko besteht darin, dass Netzwerke, die strenge Routing-Richtlinien anwenden, unbekannte Routen anders behandeln können als gültige Routen, oder dass ein zukünftiger Route-Hijack oder eine Fehlkonfiguration durch eine automatisierte Richtlinie schwerer zu filtern ist.
Für Kunden ist dies nicht die einzige Sicherheitsfrage, aber eine gute Beschaffungsfrage: Hat Media Cloud die Absicht, ROAs für seine angekündigten Präfixe zu veröffentlichen, und kann es nachweisen, dass die Routenobjekte und ROAs von der Partei mit der operativen Verantwortung verwaltet werden?
RPKI kann auch nicht die Servicequalität beweisen. Ein gültiger Routenursprung würde nicht anzeigen, wie viele Server online sind, ob Backups funktionieren, ob ein lokaler Loop eine Pfaddiversität hat oder ob ein Techniker schnell Hardware ersetzen kann. Es schließt nur eine Kategorie von Routing-Risiko. In diesem Fall macht das Fehlen einer validierenden ROA die öffentliche Kontrollebene weniger vollständig als den Produktkatalog. Diese Lücke ist reparabel, aber sie muss anerkannt werden.
Die breitere Lektion für Kunden ist, dass die Resilienz der gehosteten Kapazität viele Schichten hat. RPKI schützt die Ursprungsautorisierung. IRR-Objekte beeinflussen Filter. BGP-Nachbarn beeinflussen die Erreichbarkeit. Exchange- und Transit-Vereinbarungen beeinflussen die Pfadwahl. Einrichtung, Stromversorgung, Ersatzteile und Support beeinflussen die Reparatur. Backups und Exportpfade beeinflussen die Wiederherstellung.
Die öffentlichen Nachweise von Media Cloud sind in der Mitte dieser Kette am stärksten und an den Enden schwächer: Die Routensichtbarkeit ist klar; die Datenportabilität und getestete Wiederherstellung sind nicht öffentlich.
Medias Bedingungen beschreiben den Fehlerpfad
Die rechtlichen Seiten des Unternehmens sind keine sauberen technischen Diagramme, aber sie sind operativ aufschlussreich. DieNutzungsbedingungen von mediacloud.iddefinieren die Dienste weitgehend als Domain-Registrierung, Hosting, Website-Erstellungsdienste und Internetdienste. Die Bedingungen besagen, dass das Hosting Website-Inhalte speichert und bereitstellt und dass Internetdienste Fernsehen, E-Mail, Konnektivität und verwandte Dienste umfassen können. Sie geben auch an, dass Media Cloud kommerziell angemessene Anstrengungen unternehmen wird, um die Website und die Dienste rund um die Uhr bereitzustellen.
Derselbe Abschnitt zur Verfügbarkeit ist wichtiger als der Satz zur Verfügbarkeit. Er besagt, dass Dienste aus Gründen wie Gerätestörungen, regelmäßiger Wartung, Reparaturen oder Austausch, Gründen außerhalb der angemessenen Kontrolle, Unterbrechung oder Ausfall von Telekommunikations- oder digitalen Übertragungsverbindungen, feindlichen Netzwerkangriffen, Netzüberlastung und anderen Fehlern unzugänglich oder nicht betriebsbereit sein können. Er gibt auch an, dass Media Cloud keine Kontrolle über die kontinuierliche oder ununterbrochene Verfügbarkeit hat.
Diese Formulierung ist nicht ungewöhnlich; viele Anbieter verwenden ähnliche Haftungsausschlüsse. Hier jedoch gibt sie den Kunden eine präzise Liste der genauen Abhängigkeitskategorien, die sie testen sollten.
DieRückerstattungsrichtlinieist ebenso spezifisch. Sie besagt, dass Domain-Registrierungsgebühren in der Regel nicht erstattungsfähig sind, sobald sie registriert oder verlängert wurden; Hosting- und Website-Erstellungsdienste werden nach dem Kauf nicht erstattet; und Breitband- oder dedizierte Internetdienste können für eine Rückerstattung in Frage kommen, wenn der Dienst mehr als sieben Tage (24 Stunden ununterbrochen) unterbrochen ist oder wenn Media Cloud den Dienst aufgrund technischer Schwierigkeiten oder eines Verbots durch den örtlichen Nachbarschaftsvorsteher nicht fortsetzen kann. Dies ist eine auffällige operationelle Schwelle. Es deutet darauf hin, dass für Internetkonnektivität der Rückerstattungsauslöser in Tagen und nicht in Minuten oder Stunden gemessen wird.
Kunden sollten die Rückerstattungsberechtigung nicht mit der operationellen Resilienz verwechseln. Eine Rückerstattung nach einer Woche ununterbrochener Unterbrechung stellt keine Anwendung wieder her, migriert kein Postfach, stellt keine Datenbank wieder her und hält keinen Online-Shop während der Unterbrechung am Laufen. Sie definiert nur ein finanzielles Rechtsmittel. Ein Kunde mit kritischen Arbeitslasten sollte Service-Level-Ziele, Incident-Eskalation, proaktive Benachrichtigung, Wartungsfenster, Datenexportverpflichtungen und gemessene Wiederherstellungsziele verlangen, die von der Rückerstattungsrichtlinie getrennt sind.
Deshalb verweist der Titel des Artikels auf Racks, Transit und Reparaturfenster. Die rechtlichen Bedingungen von Media Cloud identifizieren dieselben Kategorien: Ausrüstung, Wartung, Telekommunikationsverbindungen, Überlastung und Angriff. Die öffentlichen Routing-Daten zeigen dann, wo eine große Transitabhängigkeit auftritt. Die Aufgabe des Käufers ist es, diese öffentlichen Hinweise in vertragliche und testbare Nachweise zu verwandeln.
Datenlokalisierung wird nicht durch eine indonesische Marke gelöst
Die Positionierung von Media Cloud ist stark indonesisch. Die Domain-Seite betont die.id-Identität, die VPS-Seite sagt "VPS Indonesia", die Fußzeile gibt eine Kontaktadresse in Süd-Jakarta an, und die APNIC/IDNIC-Einträge platzieren die AS und die Adressressourcen in Indonesien. Für viele Kunden, insbesondere kleine Unternehmen, kann dies der Hauptpunkt sein: ein lokaler Anbieter, eine lokale Sprache, lokale Zahlungserwartungen und Support, der über indonesische Kanäle erreichbar ist.
Aber Datensouveränität und -lokalisierung erfordern mehr als ein Länderetikett. Eine gehostete Website kann sich auf den Adressen von Media Cloud befinden, während E-Mails über Google oder Microsoft abgewickelt werden. Ein Support-Ticket kann persönliche Daten enthalten. Ein Backup kann in einem anderen System als dem Hauptserver gespeichert sein. Eine Domain-Registrierung kann Prozesse der Registrierungsstelle und des Registers umfassen. Eine DDoS-Mitigationsbehauptung kann auf einer Upstream-Filterung oder einer Drittanbieterplattform beruhen.
Jede Schicht kann Daten, Metadaten oder Zugriffsrechte an einem anderen operativen Standort platzieren.
DieDatenschutzrichtliniedes Unternehmens gibt an, dass es Kontaktinformationen, Rechnungsinformationen, Kontokennungen, vom Benutzer erstellte oder hochgeladene Inhalte, Protokolldaten, Geräteinformationen und Cookies oder ähnliche Technologien sammelt. Sie besagt, dass personenbezogene Daten mit Dienstanbietern, Drittpartnern zu Marketing- oder Werbezwecken, im Rahmen von Geschäftstransaktionen oder wenn das Gesetz dies verlangt, geteilt werden können. Sie gibt auch an, dass personenbezogene Daten in andere Länder als das des Benutzers übertragen und verarbeitet werden können und dass keine Methode der Internetübertragung oder elektronischen Speicherung vollständig sicher ist. Dies ist eine generische Datenschutzsprache, aber im Hosting-Kontext ist dies von Bedeutung: Der Anbieter erkennt die Möglichkeit einer grenzüberschreitenden Verarbeitung und Verarbeitung durch Dritte an.
Der indonesische Rechtskontext erhöht auch die Messlatte für ein klares Datenmanagement. Die Regierungsverordnung Nr. 71 von 2019 über elektronische Systeme und Transaktionen wird von JDIH Kemkomdigi unterdieser offiziellen Seiteveröffentlicht. Die Seite enthält Bestimmungen zur Registrierung von Betreibern elektronischer Systeme, Zuverlässigkeit, Sicherheit, Risikomanagement, Service-Level-Vereinbarungen und Grundsätzen der Verarbeitung personenbezogener Daten. Das Gesetz Nr. 27 von 2022 zum Schutz personenbezogener Daten wird aufJDIH Kemkomdigiveröffentlicht. Dieser Artikel behauptet nicht, dass Media Cloud für jedes Produkt in eine bestimmte regulatorische Kategorie fällt, aber der nationale Rahmen erklärt, warum Kunden fragen sollten, wo Daten, Backups, Protokolle, Tickets und Support-Zugriff tatsächlich residieren.
Der praktische Test ist einfach. Ein indonesischer VPS sollte mit einer Antwort zum Standort kommen: Wo befindet sich der Haupt-Host, wo sind die Backups, wo befindet sich die Identität der Kontrollebene, wo sind die Protokolle, und welche Drittanbieterdienste verwalten E-Mail, DNS, DDoS-Filterung, Support oder Abrechnung? Ohne diese Matrix bleibt "lokal" ein nützliches Marketingsignal, aber keine vollständige Garantie für Souveränität.
Installierte Kapazität und nutzbare Kapazität sind unterschiedlich
Der öffentliche Netzwerk-Footprint von Media Cloud unterstützt eine Erzählung von bescheidener, aber realer installierter Kapazität. Es hat eine registrierte AS, ein geroutetes IPv4-/23, aufgeteilt in zwei /24, ein IPv6-/32, öffentliche Websites im selben IPv4-Block, einen PeeringDB-Exchange-Eintrag, ein lokales Loop-Angebot und VPS-/Hosting-/E-Mail-Produkte. Dies ist konkreter als ein einfacher Reseller ohne identifizierbaren Edge. Es reicht aus, um das Interesse der Kunden zu rechtfertigen.
Die nutzbare Kapazität ist die schwierigere Frage. Ein VPS-Produkt kann dedizierte Ressourcen und NVMe-Speicher versprechen, aber die öffentlichen Seiten legen nicht offen, wie viele Hypervisoren existieren, wie der Speicher repliziert wird, ob Kunden-Backups außerhalb des Racks oder außerhalb des Standorts erfolgen, wie viele Ersatzmaschinen gelagert werden, welcher Anteil der Kapazität für Failover reserviert ist oder ob das Steuerungspanel funktionieren kann, wenn das Produktionsnetzwerk ausfällt.
Ein lokales Loop-Produkt kann 1 Gbit/s, 2 Gbit/s oder 3 Gbit/s versprechen, aber die öffentlichen Seiten legen keine Glasfaserpfade, Interkonnektionsdiversität, Betreiberdiversität oder die Überlastungspolitik im Fehlerfall offen.
Diese Unterscheidung ist im Fehlerfall wichtig. Die installierte Kapazität ist das, was ein Anbieter an einem normalen Tag verkauft. Die nutzbare Kapazität ist das, was nach einem Ausfall eines Servers, Routers, Glasfaserpfads, Upstream-Anbieters, Exchange-Ports, der Stromversorgung, einer Support-Warteschlange oder eines Abrechnungskontos übrig bleibt. Die wiederherstellbare Kapazität ist das, was innerhalb der Ausfallzeit- und Datenverlusttoleranzen des Kunden wiederhergestellt werden kann. Kunden kaufen die zweite und dritte Kategorie, ob die Rechnung sie so nennt oder nicht.
Das sichtbare Upstream-Modell von Media Cloud macht diese Unterscheidung dringlicher. Wenn die meisten globalen Collector-Pfade AS140449 über AS138840 erreichen, muss der Kunde fragen, ob AS138840 eine einzelne Upstream-Abhängigkeit, ein Haupttransitpfad, ein Routenserver-Pfad oder Teil einer breiteren Transitmischung ist, die die öffentlichen Collectoren nicht vollständig offenlegen. Wenn die OpenIXP/NiCE-Präsenz bei 1 Gbit/s liegt, muss der Kunde fragen, ob sie für settlement-freies Peering, Routenserver-Erreichbarkeit, Backup oder kritischen Kundenverkehr genutzt wird.
Wenn PeeringDB keine Standorte auflistet, muss der Kunde fragen, wo sich die Produktionsausrüstung befindet und wie der physische Zugang verwaltet wird.
Keine dieser Fragen impliziert ein Verschulden. Es sind normale Fragen der infrastrukturellen Sorgfaltspflicht. Ein kleiner Anbieter kann ausgezeichnet sein, wenn er ehrlich über seine Grenzen ist, die Wiederherstellung testet und den Kunden praktikable Ausstiegswege bietet. Ein großer Anbieter kann fragil sein, wenn er einen gemeinsamen Fehlerpunkt verbirgt. Die öffentlichen Nachweise für Media Cloud sind stark genug, um die ersten Fragen zu stellen, aber nicht stark genug, um sie abzuschließen.
Support und Abrechnung sind Teil der Infrastruktur
Media Cloud verkauft seine Produkte über einen Shop, der eine Anmeldung, Kontaktlinks und WhatsApp-Buttons erfordert. Die Fußzeile listetsupport@mediacloud.idim Shop undsupport@mci.net.idauf der Unternehmenswebsite, während mci.net.id support.mci.net.id unter 103.152.240.243 bereitstellt. Dies gibt den Kunden mehrere Support-Einstiegspunkte, aber die Resilienzfrage ist, ob diese Einstiegspunkte während eines Vorfalls ausreichend unabhängig sind.
Support ist Infrastruktur, weil er Erkennung in Reparatur verwandelt. Wenn ein VPS ausfällt, benötigt der Kunde mehr als eine generische Eingangsbestätigung. Er benötigt eine qualifizierte verantwortliche Person, eine Diagnose, einen geschätzten Wiederherstellungspfad und eine Möglichkeit, Daten wiederherzustellen, wenn die Wiederherstellung die Zeitvorgabe des Kunden überschreitet. Wenn ein lokaler Loop ausfällt, muss der Kunde wissen, ob Media Cloud einen Techniker schicken kann, ob ein Partner die letzte Meile kontrolliert und ob derselbe Stromkreis das Support-Portal trägt.
Wenn die Abrechnung ein Konto blockiert, benötigt der Kunde einen Eskalationspfad, der den Geschäftsstatus vom Notfall-Datenzugriff trennt.
Die Nutzungsbedingungen machen den Konto- und Zahlungsstatus operativ relevant. Preise können sich ändern; Nichtzahlung kann zu Sperrung oder Kündigung führen; Kunden sind für die Aufrechterhaltung der Kontosicherheit verantwortlich; Media Cloud kann den Zugang bei Verstoß sperren oder kündigen. Diese Klauseln sind Standard, aber sie zeigen, dass die Kontrollebene nicht rein technisch ist. Eine Domain, ein Hosting-Plan, ein Postfach oder ein VPS können aufgrund einer administrativen Bedingung ebenso ausfallen wie aufgrund einer Hardware-Bedingung.
Die E-Mail-Produkte machen dies noch deutlicher. Die E-Mail-Seiten beschreiben Migrationsunterstützung, Fehlerbehebung, Webmail, Anti-Spam, Anti-Virus, DKIM-Signaturen, automatische Backups, E-Mail-Tracking-Funktionen und Audit-Logs. Wenn diese Teil des Geschäftsprozesses eines Kunden sind, muss die Wiederherstellung den Export des Postfachs, die DNS-Kontinuität, die DKIM/SPF/DMARC-Kontinuität, den Archivzugriff und Support-Nachweise umfassen. Es reicht nicht zu sagen: "E-Mail wird gehostet". Der Kunde muss wissen, was passiert, wenn das E-Mail-Produkt oder seine externe Plattformabhängigkeit ausfällt.
Für Media Cloud sollte der Käufer vor der Verlagerung kritischer Arbeitslasten ein Support-Verfahrenshandbuch anfordern. Wer nimmt dringende Anrufe entgegen? Gibt es eine telefonische Eskalation für einen lokalen Loop- oder VPS-Ausfall? Sind die Support-Mitarbeiter berechtigt, Arbeitslasten zu verschieben, oder nur Tickets zu erstellen? Sind die Warteschlangen für Konto, Abrechnung und Missbrauch von der Incident-Response getrennt?
Wie schnell kann das Unternehmen einen vollständigen Export der VPS-Festplatte, der Website-Dateien, des Postfachinhalts, der DNS-Zone und des Domain-Autorisierungscodes bereitstellen, wenn der Kunde sich entscheidet zu gehen?
Das Hauptkundenrisiko ist die Konzentration
Der Komfort von Media Cloud ist auch sein Risiko. Ein Kunde kann plausibel die Domain, die Website, das Hosting, den VPS, das SSL-Zertifikat, die geschäftliche E-Mail und die dedizierte Konnektivität von derselben Markenfamilie kaufen. Dies kann das Lieferantenmanagement für ein kleines Unternehmen reduzieren. Es kann aber auch einen Anbietervorfall in einen zusammengesetzten Ausfall verwandeln: Die DNS-Verlängerung, die Zertifikatsausstellung, das Webhosting, die VPS-Erreichbarkeit, der E-Mail-Zugriff und die lokale Konnektivität können alle dasselbe Support-Team oder dieselbe Konto-Beziehung erfordern.
Die Infrastrukturversion der Konzentration ist ähnlich. Wenn der sichtbare Edge stark von AS138840 abhängt, wenn die Exchange-Oberfläche eine einzige OpenIXP/NiCE-Liste ist, wenn die Produktion sich in einer nicht offengelegten Einrichtung befindet und wenn der Support-Pfad mit demselben Netzwerk verbunden ist, dann kann ein einziges operatives Problem mehrere Ebenen betreffen. Die öffentlichen Nachweise beweisen nicht, dass all diese Single Points of Failure existieren, aber sie schließen sie auch nicht aus. Die sichtbaren Einträge reichen aus, um eine Antwort zu verlangen.
Kunden sollten die Konzentration auf vier Arten testen. Erstens: Identität und DNS vom Hosting trennen. Kann die Domain schnell übertragen werden? Können die DNS-Einträge exportiert werden? Sind die Zoneneinträge während eines Hosting-Ausfalls zugänglich? Zweitens: Rechenleistung und Backup vom Speicher trennen. Kann der Kunde einen VPS oder eine Website bei einem anderen Anbieter wiederherstellen, ohne zu warten, dass Media Cloud den ursprünglichen Host neu aufbaut? Drittens: Konnektivität vom Anwendungs-Hosting trennen. Wenn der lokale Loop ausfällt, kann der Kunde den gehosteten Dienst über einen anderen Zugangsanbieter erreichen?
Viertens: Support von der betroffenen Plattform trennen. Wenn das Service-Portal ausgefallen ist, gibt es einen unabhängigen Eskalationskanal?
Die Rückerstattungsschwelle für den lokalen Loop sollte die Gemüter schärfen. Ein über mehr als sieben aufeinanderfolgende Tage unterbrochener Dienst liegt weit über der Toleranz vieler geschäftlicher Arbeitslasten. Ein Kunde, der eine Woche lang nicht arbeiten kann, sollte sich nicht auf die Rückerstattungsrichtlinie als Kontinuitätsplan verlassen. Er sollte vor dem Kauf ein Failover, getestete Backups, alternativen Zugang und schriftliche Eskalationsbedingungen verlangen.
Dies ist die praktischste Schlussfolgerung aus der öffentlichen Akte. Media Cloud sieht aus wie ein echter operativer Anbieter mit einem identifizierbaren Netzwerk. Es ist eine Bewertung wert. Dieselben Nachweise zeigen, warum die Bewertung über die Produktseite hinausgehen muss: Ein Kunde benötigt Nachweise für Diversität, Wiederherstellung und Ausstieg.
Was ein ernsthafter Käufer als nächstes fragen sollte
Ein ernsthafter Käufer sollte mit dem Routing-Edge beginnen. Media Cloud fragen, welche Dienste AS140449 verwenden, welche Präfixe den VPS- oder Hosting-Pools der Kunden zugewiesen sind und ob sich Kundendienste hinter anderen Anbietern befinden. Fragen, ob ROAs für 103.152.240.0/24, 103.152.241.0/24 und 2406:38c0::/32 veröffentlicht werden und wer die IRR-Routenobjekte verwaltet.
Fragen, ob AS138840 der Haupttransit, ein Backup-Transit, eine Routenserver-Nachbarschaft oder eine andere Beziehung ist und ob es einen zweiten unabhängigen Transitpfad mit ausreichender bezahlter Kapazität gibt, um den Kundenverkehr im Fehlerfall zu transportieren.
Als nächstes nach dem Einrichtungsmodell fragen. Welche(s) Rechenzentrum/Rechenzentren hosten die VPS- und Hosting-Produkte? Sind die Racks im Eigentum, gemietet oder untervermietet? Gibt es separate Stromversorgungen, separate Router, separate Firewalls und separate Glasfaseranschlüsse? Wird OpenIXP/NiCE für kritischen Kundenverkehr genutzt, und hat der 1-Gbit/s-Exchange-Port eine Überlastungsüberwachung?
Wenn PeeringDB keine Standorte auflistet, liegt das daran, dass das Unternehmen sich entscheidet, sie nicht offenzulegen, weil das Netzwerk über einen Partner bereitgestellt wird, oder weil die Arbeitslasten der Kunden nicht in einer öffentlichen Interkonnektionseinrichtung platziert sind?
Drittens nach Wiederherstellungstests fragen. Wann fand die letzte Wiederherstellung einer VPS-Festplatte statt? Wie lange dauerte sie? Wurde sie auf demselben Host, einem anderen Host in derselben Einrichtung oder an einem anderen Standort wiederhergestellt? Wie werden die Backups von WordPress- und Sitejet-Hosting gespeichert? Kann ein Kunde einen Export testen, ohne den Dienst zu kündigen? Wird E-Mail so gesichert, dass der Kunde sie wiederherstellen kann? Sind DKIM-Schlüssel, DNS-Zonen, Zertifikate und Postfacharchive in einem Ausstiegspaket enthalten?
Viertens nach den Support-Grenzen fragen. Was ist der Major-Incident-Pfad für VPS-, Hosting-, Domain-, E-Mail-, SSL- und lokale Loop-Dienste? Welche Kontaktmethode bleibt verfügbar, wenn mci.net.id oder mediacloud.id nicht erreichbar ist? Erstellt der WhatsApp-Support ein formelles Ticket? Gibt es definierte Antwort- und Wiederherstellungszeiten? Welche Ereignisse lösen Kundenbenachrichtigungen vor Beginn der Wartung aus?
Schließlich fragen, wie die rechtlichen und datenschutzrechtlichen Aussagen mit der tatsächlichen Datenplatzierung übereinstimmen. Die Datenschutzrichtlinie erlaubt grenzüberschreitende Verarbeitung, und die DNS/MX-Nachweise zeigen eine Abhängigkeit von globalen Plattformen für einige Teile des Unternehmens. Der Kunde sollte fragen, wo personenbezogene Daten, Protokolle, Backups, Tickets und Abrechnungsaufzeichnungen verarbeitet werden und ob ein Produkt vertraglich in Indonesien gehalten werden kann.
Diese Fragen sind nicht feindselig. Sie sind die Art und Weise, wie ein Käufer das sichtbare öffentliche Netzwerk von Media Cloud in eine getestete Abhängigkeit verwandelt. Das Unternehmen hat genügend öffentliche Nachweise, um das Gespräch zu rechtfertigen. Es hat noch nicht genügend öffentliche Nachweise, um Kunden zu erlauben, es zu überspringen.
Das Beweislevel
PT Media Cloud Indonesia erhält ein öffentliches Beweislevel von Mittel. Das Level ist kein Qualitätsscore für das Unternehmen; es ist ein Score dafür, was die öffentlichen Nachweise stützen können. Positiv: Identität und Betriebsoberfläche sind für einen regionalen Hosting-Anbieter ungewöhnlich konkret. APNIC/IDNIC verbindet das Unternehmen mit AS140449, 103.152.240.0/23 und 2406:38c0::/32. RIPEstat hat drei aktive, im Juli 2026 angekündigte Präfixe gesehen. Die öffentlichen Websites lösen im eigenen IPv4-Block des Unternehmens auf.
Media Cloud bewirbt eine spezifische Produktpalette: Domains, Hosting, VPS, SSL, E-Mail, Webdienste und lokale Loop-Konnektivität. PeeringDB listet das Netzwerk und einen OpenIXP/NiCE-Anschluss.
Die Abwertungsbedenken betreffen die Resilienznachweise. Die öffentlichen Nachweise nennen keine Produktionseinrichtung. PeeringDB listet keinen Standorteintrag. Die Routenursprungsvalidierung gab "unbekannt" für die überprüften Präfixe zurück. Die sichtbaren BGP-Pfade sind stark mit AS138840 verbunden, und das IPv6-Routenobjekt beschreibt eine per Proxy registrierte HSP Global-Kundenroute. Die eigenen Bedingungen von Media Cloud besagen, dass Dienste durch Gerätestörungen, Wartung, Reparatur, Telekommunikationsausfälle, Angriffe, Überlastung und andere Ursachen unterbrochen werden können.
Die Rückerstattungsrichtlinie deutet darauf hin, dass einige Rechtsmittel für Internetdienste um eine längere ununterbrochene Unterbrechung herum gestaltet sind und nicht um eine kurze operative Ausfallzeit.
Diese Kombination unterstützt eine klare Schlussfolgerung: Media Cloud ist ein echter indonesischer Anbieter von gehosteten Diensten und Konnektivität mit einem sichtbaren Netzwerk, aber Kunden sollten das sichtbare Netzwerk nicht als Beweis für Multi-Site-Cloud-Resilienz betrachten. Der angemessene Due-Diligence-Pfad besteht darin, den Standort der Einrichtungen, die Transitdiversität, die Routenursprungskontrollen, Backup- und Wiederherstellungstests, die Support-Eskalation, die Abrechnungskontinuitätsregeln und die Datenexportrechte zu überprüfen.
Wenn diese Überprüfungen zufriedenstellend sind, geben die öffentlichen Nachweise den Kunden etwas Solides zu überwachen. Wenn diese Überprüfungen fehlen, kann die Bequemlichkeit eines gebündelten lokalen Anbieters zu einer konzentrierten Abhängigkeit werden.

