Informacje Lokalne

ZdrowiePOLSKALOKALNESWIATHYDEPARK

Audyt techniczny. Kolumbia

Opublikowano: 16.02.2026 | Autor: Grzegorz GPS Świderski | Ostatnia aktualizacja: 16.02.2026 19:04

Warstwa brzegowa systemu e-faktury B2B (validación previa)

Cel audytu

Celem jest ustalenie, czy publiczne komponenty infrastruktury e-faktury w Kolumbii:

  • korzystają z globalnego WAF/CDN-as-a-Service jako reverse-proxy w torze transmisji (data-plane),
  • delegują DNS do vendorów,
  • ujawniają fingerprinty warstwy pośredniej (edge / WAF / reverse proxy),
  • oraz czy jest to model zbliżony do Polski (zewnętrzny vendor w data-plane), czy inny (hosting/edge hyperscalera).

Audyt wykonano z sieci publicznej, bez uwierzytelnienia. Badane hosty (dwa kluczowe komponenty DIAN):

factura-electronica.dian.gov.co
catalogo-vpfe-hab.dian.gov.co

1. DNS – rekordy A / AAAA / CNAME

Komenda

$hosts = @(
  "factura-electronica.dian.gov.co",
  "catalogo-vpfe-hab.dian.gov.co"
)

foreach($h in $hosts){
  foreach($t in "A","AAAA","CNAME"){
    Resolve-DnsName $h -Type $t
  }
}

Wynik – host 1: factura-electronica.dian.gov.co

Łańcuch CNAME:

factura-electronica.dian.gov.co
  CNAME msfacturaelectdian.azurewebsites.net
    CNAME waws-prod-bn1-027.sip.azurewebsites.windows.net
      CNAME waws-prod-bn1-027.eastus2.cloudapp.azure.com
        A 13.77.83.246

Interpretacja

To jest klasyczny fingerprint Azure App Service (azurewebsites.net) i hostingu w regionie Azure (eastus2). W tym komponencie:

  • występuje chmura hyperscalera (Microsoft Azure),
  • ale nie występuje globalny vendor typu Imperva/Cloudflare/Akamai w DNS.

Wniosek cząstkowy

Model: hosting aplikacji w Azure (App Service), bez śladu niezależnego vendor-WAF w DNS.

Wynik – host 2: catalogo-vpfe-hab.dian.gov.co

Łańcuch CNAME:

catalogo-vpfe-hab.dian.gov.co
  CNAME ...azurefd.net
    CNAME mr-z01.tm-azurefd.net
      A 150.171.109.51 (również 150.171.109.50 / .53)
      AAAA 2603:1061:14:34::1

Interpretacja

azurefd.net to Azure Front Door – globalny edge reverse-proxy Microsoftu (często z opcjonalnym WAF). To oznacza, że co najmniej jeden komponent DIAN działa w modelu globalny edge hyperscalera w torze HTTP(S).

Wniosek cząstkowy

Model: globalny edge reverse-proxy (Azure Front Door) dla komponentu VPFE.

2. HTTP – fingerprint warstwy brzegowej (nagłówki/cookies)

Komenda

$h = "factura-electronica.dian.gov.co"
curl.exe -vkI "https://$h/" 2>&1

Wynik – host 1

HTTP/1.1 200 OK
Server: Microsoft-IIS/10.0
Set-Cookie: ARRAffinity=...
Set-Cookie: ARRAffinitySameSite=...
X-Powered-By: ASP.NET

Interpretacja

ARRAffinity to charakterystyczny cookie Azure dla routingu sesji w App Service / Application Request Routing. Brak fingerprintów vendor-edge typu:

  • Cloudflare (cf-ray, server: cloudflare)
  • Akamai (AkamaiGHost, akamai-*)
  • Imperva (X-CDN: Imperva, incap_*)

Wniosek cząstkowy

Model: Azure App Service / IIS origin, bez zewnętrznego CDN/WAF-as-a-Service w warstwie HTTP.

Komenda (host 2)

$h = "catalogo-vpfe-hab.dian.gov.co"
curl.exe -vkI "https://$h/" 2>&1

Wynik – host 2

HTTP/1.1 302 Found
Location: /User/Login
x-azure-ref: ...
X-Cache: CONFIG_NOCACHE

Interpretacja

Nagłówek x-azure-ref jest typowym fingerprintem Azure edge (Front Door). To nie jest „ukryty origin”; to jest jawne przyznanie się warstwy pośredniej hyperscalera.

Wniosek cząstkowy

Model: globalny edge reverse-proxy Microsoft (Azure Front Door) w torze odpowiedzi HTTP.

3. TLS – certyfikaty

Komenda

$h = "factura-electronica.dian.gov.co"
$req = [System.Net.HttpWebRequest]::Create("https://$h/")
$req.Method = "GET"
$req.AllowAutoRedirect = $false
try { $resp = $req.GetResponse() } catch { $resp = $_.Exception.Response }
$cert = $req.ServicePoint.Certificate
$cert.Subject
$cert.Issuer
$cert.GetEffectiveDateString()
$cert.GetExpirationDateString()

Wynik – host 1 (factura-electronica)

Subject: CN=dian.gov.co, O=U.A.E. DIAN ...
Issuer : GeoTrust EV RSA CA 2018 (DigiCert)
From   : 25.05.2022
To     : 26.05.2023

Interpretacja

Cert pokazany przez klienta jest „instytucjonalny” (DIAN), wystawiony przez komercyjny CA. Uwaga techniczna: daty ważności wskazują na certyfikat, który wygląda na wygasły. To może oznaczać jedną z trzech rzeczy:

  • na warstwie pośredniej jest cache/rewriting certów,
  • klient widzi inny cert niż ten faktycznie użyty przy handshake (rzadkie, ale bywa przy renegocjacji),
  • albo konfiguracja certów po stronie serwera jest niespójna.

To nie jest kluczowe dla tezy „vendor-edge”, ale jest ciekawym znaleziskiem pobocznym.

Wniosek cząstkowy

TLS: cert DIAN, brak sygnałów Cloudflare/Akamai/Imperva. Hosting: Azure.

Komenda (host 2)

$h = "catalogo-vpfe-hab.dian.gov.co"
$req = [System.Net.HttpWebRequest]::Create("https://$h/")
$req.Method = "GET"
$req.AllowAutoRedirect = $false
try { $resp = $req.GetResponse() } catch { $resp = $_.Exception.Response }
$cert = $req.ServicePoint.Certificate
$cert.Subject
$cert.Issuer
$cert.GetEffectiveDateString()
$cert.GetExpirationDateString()

Wynik – host 2 (catalogo-vpfe-hab)

Subject: CN=catalogo-vpfe-hab.dian.gov.co
Issuer : GeoTrust TLS RSA CA G1 (DigiCert)
From   : 22.12.2025
To     : 23.06.2026

Interpretacja

Cert jest wystawiony bezpośrednio dla hosta DIAN i obsługiwany w architekturze z Azure Front Door (co potwierdza x-azure-ref).

Wniosek cząstkowy

TLS działa w modelu „DIAN cert + Microsoft edge”.

4. Synteza techniczna (Kolumbia)

Kolumbia pokazuje dwa równoległe komponenty:

  1. Azure App Service (hosting aplikacji):
    factura-electronica.dian.gov.co → azurewebsites.net → 13.77.83.246
    fingerprint: ARRAffinity, IIS/10.0, brak vendor-edge.
  2. Azure Front Door (globalny edge reverse-proxy):
    catalogo-vpfe-hab.dian.gov.co → azurefd.net
    fingerprint: x-azure-ref, X-Cache.

Brak natomiast fingerprintów niezależnych vendorów typu Imperva/Cloudflare/Akamai.

5. Wniosek końcowy dla Kolumbii

Infrastruktura DIAN korzysta z chmury Microsoft Azure zarówno jako hostingu (App Service), jak i globalnego edge reverse-proxy (Azure Front Door) dla komponentu VPFE.

To oznacza:

  • vendor-edge istnieje, ale jest to edge hyperscalera (Microsoft),
  • nie widać zewnętrznego, niezależnego WAF-as-a-Service typu Imperva.

6. Znaczenie porównawcze (w kontekście tezy o Polsce)

Kolumbia jest istotnym kontrprzykładem, bo pokazuje, że państwo może użyć globalnego edge reverse-proxy w e-fakturze ale robi to jako część platformy hyperscalera (Azure Front Door) a nie jako niezależny vendor WAF-as-a-Service. Jeśli Polska używa Impervy jako obowiązkowego reverse-proxy w data-plane, to różnica pozostaje jakościowa:

  • Kolumbia: Microsoft edge hyperscalera
  • Polska: zewnętrzny WAF-as-a-Service (Imperva)

7. Ocena końcowa audytu

Status:
Wykryto globalny edge (Azure Front Door) dla jednego komponentu DIAN.

Model infrastrukturalny:
➡️ Chmura hyperscalera (Azure) + globalny edge (Front Door) + hosting App Service.

Wpływ na hipotezę badawczą:
➡️ Osłabia tezę „nikt poza Polską nie ma vendor-edge”, ale wzmacnia tezę „Polska jest szczególna przez wybór niezależnego WAF-as-a-Service poza hyperscalerem”, jeśli to potwierdzone.

Grzegorz GPS Świderski
Kanał Blogera GPS
GPS i Przyjaciele
X.GPS65

Dodaj komentarz: