Governance su larga scala di AWS

Le grandi organizzazioni, con più team che sviluppano e gestiscono le proprie applicazioni Web o API, utilizzano strumenti e processi per promuovere l'uniformità dei controlli di sicurezza tra i team, per evitare endpoint esposti con protezioni deboli o assenti. La Gestione dei firewall AWS è uno strumento che l'organizzazione può utilizzare per gestire le implementazioni di AWS WAF e Shield Advanced su larga scala.

Firewall Manager consente di definire policy AWS WAF o Shield Advanced che vengono implementate automaticamente su risorse esposte pubblicamente, come distribuzioni CloudFront, ALB o gateway API. Una policy è composta da:

• Un ambito che definisce dove si applica: Quale tipo di risorse (CloudFront, ALB, ecc.)? includere o escludere risorse con tag specifici? quali account o unità organizzative includere o escludere?
• Regole che definiscono quali gruppi di regole WAF applicare? se abilitare la registrazione centralizzata e se aggiungere le protezioni Shield Advanced.
• Un'azione che definisce cosa fare quando una risorsa viene trovata nell'ambito di una policy. Ad esempio, è possibile applicare automaticamente le regole delle politiche o semplicemente segnalarle. In un'implementazione iniziale di Firewall Manager, si consiglia di iniziare senza una correzione automatica, per identificare le risorse che richiedono una gestione manuale con un impatto minimo sulle applicazioni esistenti. Quando viene raggiunta una maggiore affidabilità, è possibile passare alla correzione automatica di Firewall Manager.

Per utilizzare Firewall Manager, si considerino innanzitutto i suoi prerequisiti. Si noti che AWS Config è uno dei prerequisiti di Firewall Manager. Per ottimizzare il costo di AWS Config, se abilitato solo per l'utilizzo di Firewall Manager, è opportuno limitare i tipi di risorse per registrare le impostazioni alle risorse pertinenti allo scenario (ad esempio WAF, CloudFront Distribution, sistema di bilanciamento del carico, ecc.). Tenere inoltre presente che le policy sono costrutti regionali (ad esempio, si ha bisogno di una policy globale per CloudFront e di una politica regionale in ogni regione in cui si dispone di risorse regionali come ALB e API Gateway). Considerare questa soluzione AWS per facilitare l'implementazione delle policy di Firewall Manager tra le AWS Organizations

Quando si crea una policy WAF, Firewall Manager implementa un WAF WebACL con le regole WAF della policy negli account AWS nell'ambito della policy. In una policy WAF, è possibile definire due tipi di gruppi di regole che vengono aggiunti al WebACL implementato da Firewall Manager:

• Un primo gruppo di regole, che verrà valutato prima di qualsiasi altra regola.
• Un ultimo gruppo di regole, che verrà valutato alla fine.

Ciò consente di offrire a un team di sicurezza centrale la possibilità di gestire gruppi di regole comuni in tutta l'organizzazione, dando al contempo ai team applicativi la possibilità di aggiungere regole personalizzate pertinenti alla propria applicazione, tra il primo e l'ultimo gruppo di regole comuni. Poiché le regole in AWS WAF vengono valutate per ordine, il primo gruppo di regole comuni viene valutato prima di qualsiasi altra regola, seguito dalle regole create dai team dell'applicazione e infine dall'ultimo gruppo di regole comuni.

È possibile creare una pipeline CI/CD per aggiornare i gruppi di regole WAF comuni nella policy AWS WAF sull'account amministrativo AWS, che viene poi distribuito da Firewall Manager in tutta l'organizzazione in pochi minuti. Scopri in questo blog come OLX ha implementato una policy WAF centrale utilizzando una pipeline CI/CD, con un sistema di registrazione centrale.

Firewall Manager è uno strumento flessibile che consente di stabilire varie strategie di governance della sicurezza in base ai requisiti dell'organizzazione. In qualsiasi governance di sicurezza centralizzata, è necessario trovare un compromesso tra quanto si applicano le regole a livello centrale per aumentare i livelli di protezione e quanto si desidera gestire i falsi positivi causati da regole comuni implementate centralmente.

Se si dispone di team applicativi altamente autonomi e si desidera evitare di gestire i falsi positivi, creare un'unica policy WAF centrale che affronti le minacce critiche. Ad esempio, è possibile creare regole WAF basate su limiti di velocità con soglie elevate, combinati con elenchi di reputazione IP dannosa ad alta affidabilità e regole di blocco geografico per i paesi sottoposti a embargo. È possibile anche abilitare Shield Advanced e attivare la mitigazione automatica degli attacchi DDoS a livello di applicazione. Queste regole tendono ad avere un numero molto basso di falsi positivi ma sono efficaci nella protezione dai flood HTTP. Inoltre, quando vengono scoperte vulnerabilità Zero Day critiche e ad alto impatto, è possibile applicare le mitigazioni centralmente utilizzando il gruppo di regole comuni WAF implementate.

Si consiglia di creare un wiki interno per i team di applicazione, con indicazioni sulle best practice per l'aggiunta di regole WAF personalizzate nel loro WebACL, pertinenti alla propria applicazione. Ad esempio, guidandoli nell'aggiungere protezioni contro gli attacchi SQLi e XSS se la loro applicazione è vulnerabile a tali attacchi.

Se si desidera aumentare la copertura di sicurezza centrale per una gamma più ampia di minacce, rafforzare i gruppi di regole comuni centrali, ma offrendo ai team applicativi la possibilità di gestire i falsi positivi in modo autonomo. Per implementare questo modello di governance WAF, inserire le proprie regole comuni nel primo gruppo di regole della policy WAF in modalità conteggio. Queste regole emetteranno solo etichette, che si possono utilizzare nell'ultimo gruppo di regole della politica WAF per bloccare le richieste che corrispondono a queste etichette.

Se i team addetti alle candidature riscontrano falsi positivi, possono creare regole di esclusione utilizzando le etichette emesse dalle regole. Per illustrarlo con un esempio, si consideri lo scenario in cui Amazon Managed Rules (AMR) per la protezione da SQLi viene aggiunto in modalità conteggio al primo gruppo di regole. Nell'ultimo gruppo di regole, una regola blocca le richieste con l'etichetta label_matched=”SQLi_BODY” emesse dal suddetto AMR. Se l'AMR introduce un falso positivo in un'applicazione su un URL specifico (url=”/form1”), il team dell'applicazione può creare una regola di esclusione nel WebACL per mitigare questo falso positivo (ad es. SE url=”/form1” E label_matched=”SQLI_body” allora ABILITA). L'azione della regola di abilitazione sta terminando, il che significa che AWS WAF smetterà di valutare le successive regole di blocco.

Per implementare le modifiche a questa policy senza influire sulle applicazioni esistenti, si consideri la creazione di una replica di questa policy da utilizzare negli ambienti di gestione dai team applicativi. Entrambe le policy devono avere ambiti che si escludono a vicenda. Ad esempio, la policy di produzione si applica a tutte le distribuzioni CloudFront ad eccezione di quelle con tag gestione e la policy di gestione a tutte le distribuzioni CloudFront con il tag gestione. Per la maggior parte degli aggiornamenti, è possibile prima implementarli nella policy di gestione e notificare tutti i team applicativi utilizzando un argomento SNS. Una volta informati di una modifica, i team applicativi testano la nuova versione della policy nel loro ambiente di gestione, che può essere automatizzato, e gestiscono i falsi positivi, se necessario. Quindi, dopo un ritardo concordato, il team centrale propaga la modifica alla policy di produzione. Gli aggiornamenti critici che hanno una scadenza di una settimana, come le protezioni contro Log4j CVE, possono essere applicati immediatamente a scapito di alcuni falsi positivi temporanei, fino a quando i team applicativi non gestiranno le eccezioni.

Se stai cercando di applicare una linea di base di sicurezza coerente pur consentendo alcune personalizzazioni da parte degli amministratori degli account. Questo articolo illustra i passaggi per progettare e implementare una policy di base di sicurezza gestita centralmente. Descrive inoltre le migliori pratiche per il test e l'implementazione della policy.

Se si hanno gli stessi requisiti di prima, ma si desidera ridurre il carico cognitivo derivante dal rafforzamento della sicurezza delle applicazioni sui team applicativi, si consideri la creazione di un catalogo di policy per i diversi tipi di applicazioni presenti nell'organizzazione. Ad esempio, è possibile avere un catalogo con due politiche:

• Prima policy: consigliata per proteggere le applicazioni basate su Wordpress
• Seconda policy: consigliata per proteggere le applicazioni PHP con un database SQL. È possibile creare due versioni di questa policy, con diversi livelli di sensibilità del blocco. In questo modo i team applicativi possono scegliere quello che soddisfa i loro requisiti di sicurezza (livello paranoia) e la loro disponibilità a gestire i falsi positivi.
  
  

L'ambito di ciascuna policy è definito da un tag specifico (ad esempio wordpress per la prima policy e LAMP_HIGH/LAMP_LOW per la seconda policy). I team applicativi consultano il catalogo delle policy disponibili e applicano il tag della policy desiderata alle proprie risorse. Firewall Manager associa automaticamente i WebACL WAF alle proprie risorse.

Si noti che con questo approccio è possibile gestire i falsi positivi e i cambiamenti di fase nello stesso modo descritto nella sezione precedente.

A livello di applicazione, puoi utilizzare segnali personalizzati per identificare comportamenti anomali, in base a quanto previsto dall'applicazione. Ad esempio, si può prevedere che gli utenti navighino nell'applicazione in un determinato ordine o che non ordini determinati prodotti da/verso determinati paesi in base al suo indirizzo registrato. Utilizzando tali segnali, è possibile automatizzare la risposta utilizzando AWS WAF, ad esempio bloccando o contestando l'utilizzo delle richieste CAPTCHA provenienti da IP con comportamenti sospetti a livello di applicazione. Per iniziare con il concetto di automazione WAF basata su segnali applicativi, si considerino gli esempi in questa soluzione AWS.

Le automazioni avanzate includono:

• Utilizzo degli eventi ad alto rischio emessi da Cognito durante il processo di accesso/registrazione.
• Utilizzo degli eventi ad alto rischio identificati da Fraud Detector. Fraud Detector utilizza il machine learning (ML) e 20 anni di esperienza nel rilevamento delle frodi di Amazon Web Services (AWS) ed Amazon.com per identificare automaticamente attività potenzialmente fraudolente eseguite da umani e bot in tempo reale. Fraud Detector consente di rilevare le frodi analizzando il comportamento degli utenti a livello di applicazione, utilizzando i dati storici sulle frodi per addestrare, testare e implementare modelli di machine learning personalizzati per il rilevamento delle frodi adattati al caso d'uso.

Se si preferisce trasferire completamente la gestione del WAF dai team applicativi al team di sicurezza centrale, si crei una policy dedicata per ogni team applicativo, con un ambito che si applichi solo ai loro account AWS. In questo scenario, è necessario creare processi per la configurazione iniziale e canali di comunicazione tra i team delle applicazioni e il team di sicurezza centrale per operazioni come la gestione dei falsi positivi.

• Whitepaper: esempi di governance tratti dalle linee guida per l'implementazione del whitepaper AWS WAF
• Intervento tratto da AWS re:InForce 2024: in che modo Twilio gestisce le policy AWS WAF su larga scala
• Trova i partner di distribuzione AWS WAF
• Blog: Modelli operativi per la governance della sicurezza delle app Web in AWS