Topologie di rete

I cinque modi in cui una rete cliente raggiunge TRANXACT, cosa prepara il team di rete per una VPN o una connessione privata, pianificazione degli indirizzi /22 e layout della sottorete, peering hub-and-spoke, DNS e certificati, traffico in uscita e accesso dell'operatore.

La rete è il punto in cui la maggior parte delle implementazioni perde tempo. Tutte le opzioni elencate di seguito sono disponibili su AWS, Microsoft Azure e Google Cloud; l'unica differenza sta nel nome del prodotto.

Cinque opzioni di connettività

Cosa prepara il team di assistenza clienti, per regione

Pianificazione degli indirizzi

• Almeno un intervallo privato /22 (RFC 1918) per regione — 1.024 indirizzi.
• Un secondo /22 diverso per la regione Live DR.
• Nessuna delle due può sovrapporsi alla rete di clienti, partner o landing zone, ovvero uffici, data center o altri cloud.
• Gli intervalli di pod e servizi Kubernetes sono pianificati all'interno o a fianco dell'intervallo e sono soggetti alla stessa regola di non sovrapposizione se vengono instradati.
• Evitate gli intervalli riservati e link-local del provider cloud.
• La definizione degli intervalli è compito del cliente (INFRA_2.2.02, Escluso). La modifica degli intervalli dopo la compilazione comporta una nuova compilazione (INFRA_2.2.12, Servizio aggiuntivo, tramite richiesta di modifica).

Prima di scegliere, raccogli il piano IP completo del cliente. Una singola sovrapposizione può bloccare contemporaneamente VPN, peering e routing di ripristino di emergenza, mentre la mancanza di una sola sottorete /22 può rallentare l'intera configurazione.

Le sottoreti all'interno di una regione

Un modo per definire 10.40.0.0/22 — un esempio a scopo formativo, non uno standard TRANXACT; il Ledger Architect definisce il piano reale in fase di progettazione:

Primary region   10.40.0.0/22   (10.40.0.0 - 10.40.3.255)
  ingress        10.40.0.0/26
  gateway        10.40.0.64/27
  admin          10.40.0.96/27
  egress (NAT)   10.40.0.128/27
  database AZ1   10.40.0.192/27
  database AZ2   10.40.0.224/27
  nodes AZ1      10.40.1.0/24
  nodes AZ2      10.40.2.0/24
  nodes AZ3      10.40.3.0/24

Live DR region   10.40.4.0/22   (same layout, never overlapping the primary)

Peering: modello hub and spoke

Per un cliente con una landing zone esistente nello stesso cloud, TRANXACT funge da spoke e la landing zone del cliente da hub. Il peering rappresenta il punto di demarcazione. Il gateway hub instrada il traffico verso uffici e data center, e il cliente può installare i propri firewall o appliance virtuali di rete nell'hub.

Risoluzione dei nomi e certificati

Utenti e integrazioni si connettono a un unico nome indipendente dalla posizione. Questo nome viene risolto tramite il gestore del traffico in entrambe le regioni di produzione, pertanto un failover di Live DR non richiede alcuna riconfigurazione.

Dati in transito

Il cliente elenca tutte le destinazioni in uscita (INFRA_2.6.03, Escluse); TRANXACT gestisce la lista di autorizzazione, una richiesta di servizio per destinazione (INFRA_2.6.02).

Come gli operatori di TRANXACT entrano

• Tramite un punto di accesso zero-trust o bastion nella sottorete amministrativa dedicata. Nessun nodo o database è esposto direttamente.
• Elevazione just-in-time, a tempo limitato, approvata per ogni modifica o incidente — approvata dal cliente (TO_4.5.05, Escluso).
• Autenticazione a più fattori (MFA) su ogni identità dell'operatore; principio del minimo privilegio; basata sui ruoli.
• Ogni sessione amministrativa e ogni chiamata API cloud vengono registrate ed esportate nel SIEM del cliente.
• Gli operatori gestiscono la piattaforma. L'accesso ai dati aziendali è consentito solo tramite un ticket approvato dal cliente.

Scenari di integrazione comuni

Ogni integrazione avviene tramite le API di TRANXACT o il trasferimento gestito di file. Nessun componente si connette direttamente al database.

Segui il corso su questo, con diagrammi e una verifica