Hai qualche suggerimento per sensibilizzare il business nella rinegoziazione degli SLA?
Ricontrollare gli SLA dei servizi che compongono l’architettura in cloud può permettere di ridurre i requisiti in termini di potenza computazionale o passare a computazione asincrona o in batch. Questo porta a un utilizzo più efficiente dell’infrastruttura e a una riduzione del consumo energetico e quindi delle emissioni. Dalle conversazioni con i clienti abbiamo notato che spesso i servizi sono implementati in modo superare gli SLA stabiliti. In questi casi non è necessario rinegoziarli, ma si possono riadattare le performance rispettando i livelli richiesti. Negli altri casi è importante mantenere un approccio data driven. La rinegoziazione deve essere guidata dall’incrocio degli effetti di una modifica degli SLA sugli utenti finali e delle misure indirette di efficienza energetica che si otterrebbero. Incrociando queste informazioni si valutano i compromessi e il punto operativo migliore per il proprio business.

È possibile utilizzare il processo del video hashing con live stream?
Si`, ma si introdurra` una latenza difficile da rimuovere: anche ammesso di mandare 1 frame al secondo (quindi con un campionamento selvaggio), ci vorrebbero secondi per avere una decisione e, dato che i livestream di solito durano ore, questo ritardo si accumulerebbe nel tempo e sarebbe difficile intervenire al volo quando necessario. A meno di non trasmettere in differita, tipo di 20 minuti.

Non ci sono limitazioni dovute al fatto che sia necessario avere un'enorme libreria di contenuti non consentiti già hashati? Come bloccare i nuovi contenuti?
La piattaforma ThreatExchange che Meta gestisce serve proprio a questo: a costruire una libreria di contenuti gia` hashati che la community possa condividere, svolgendo un lavoro di coordinamento simile a quello di NCMEC per la pedopornografia. Chiunque si puo` iscrivere e chiunque puo` contribuire. I nuovi contributi possono venire inseriti dai vari attori che aderiscono all'iniziativa proprio in questo modo.

Perché non usare un qualunque altro API gateway presente sul mercato?
Principalmente per due motivi, la prima (come spiegato durante il talk) è quello che non volevamo nessun single point of failure. Utilizzando Rond se introduciamo un problema sulle policy/configurazione queste potrebbero causare disservizi solo ed esclusivamente sul container che le utilizza lasciando il resto del sistema up&running. Il secondo punto è quello di proteggere anche le richieste interne del cluster tra microservizi diversi.

Come cambiano le performance dopo l'aggiunta di Rond davanti al nostro container? Come si proteggono i container che consumano o pubblicano su message brokers?
Rond viene deployato (nella configurazione standard) come sidecar container, è sviluppato in Go, e lato performance tutto dipende dalle valutazioni delle singole policy (e dalla loro complessità). Generalmente se parliamo di performance di esecuzione in termini di tempo tutto dipende dalla valutazione che la policy fa, generalmente per controlli standard (esempio decodifica di un JWT, controllo permessi e applicazione di un filtro) l'overhead temporale è minimo. Rond è pensato per funzionare su richieste HTTP/HTTPS ad oggi non è possibile proteggere i container che invece sfruttano sistemi basati su event streaming.

Integrabilità con soluzioni SSO?
In generale Rond è agnostico al sistema di autenticazione. Questo significa che un SSO lavora indipendentemente da Rond, autenticherà l'utente e produrrà il sistema di autorizzazione (immaginiamo un token, un JWT o qualsiasi altra cosa) e questo sarà utilizzato da Rond per autorizzare le richieste e/o applicare filtri.

C'è un esempio su github?
https://github.com/Vista-Technology/CloudConf2022-Torino

Le regole custom di Falco possono essere definite a livello di singolo pod?
La risposta è si. Proprio per la granularità con cui è organizzata la raccolta dati riesco ad avere evidenza per segregare addirittura fino al container all’interno di un POD. Posso quindi usare questi valori per produrre regole molto specifiche, anche su singolo POD.

Quanto incidono sulle risorse (anche ambientalmente) l'utilizzo degli strumenti indicati?
L’impatto in termini di risorse dell’agente Falco è davvero molto molto piccolo, direi quasi trascurabile. Si parla quindi di un container che occupa pochissimi millicore e pochi Mb di RAM (a volte anche sotto il Mb). Per esperienza tutti gli agenti che si basano su tecnologia eBPF hanno tutti questo vantaggio rispetto ad altre tecnologie

Quindi mi sembra di capire che alcuni dei vantaggi di questi prodotti sono un controllo più automatizzato degli eventi in un'architettura a containers e la capacità di agire in base ai dati che raccoglie, corretto?
Corretto. Il più grande vantaggio di questo tipo di soluzione è la visibilità, intesa proprio come capacità di ottenere un grandissimo numero di informazioni (in questo caso si potrebbe dire proprio tutte) riguardo ad una applicazione containerizzate che gira. La visibilità è requisito fondamentale che ci porta ad avere un’automazione buona o non buona. Più le informazioni non sono precisi e puntuali e più un processo di automazione non riesce ad essere preciso e puntuale.

Avete pensato di fare event sourcing / cqrs magari con Kafka come source of truth?
In realtà abbiamo fatto Event Sourcing e CQRS ma utilizzando i servizi nativi di AWS, quindi niente Kafka ma SQS e SNS. La scelta di rimanere sui servizi di AWS è stata semplicemente per cercare di non avere troppa frammentazione di vendor e perchè il team, sia dev che infrastrutturale, aveva già un buon know how dei servizi Amazon.

Vorrei chiederle come viene effettuata nell'architettura presentata la sincronizzazione dei dati contenuti nei database dedicati a ciascun microservizio. Se usando code e topic (sqs/sns) oppure attraverso altre tecniche.
La sincronizzazione tra i vari database nel nostro caso avviene in due modi:

- Chiamata gRPC: Questo sistema cerchiamo di usarlo poco, praticamente solo nei casi in cui si ha la necessità di recuperare un dato il cui output è dato dalla logica di business di un determinato microservices o nel caso il Microservice A ha neccessità di asptterare che il B abbia fatto le sue cose prima inviare la risposta al client;
- Sottoscrizione evento SNS via HTTPS: È il sistema che utilizziamo di più, latenza bassa (siamo sotto il secondo prima di avere la notifica), e l'aumentare delle richieste HTTPs rientra nelle normali metriche di scaling nel caso ci troviamo in una situazione in cui il numero di eventi sollevati cresca per un qualche motivo;
- Coda SQS: tutti quei casi il cui il microservice di destinazione può tranquillamente aspettare per avere il dato (ETL, Audit, ...);

Come sono gestiti i worker?
La famiglia dei worker è una manna dal cielo perché lavorano su thread separati e quindi aiutano sensibilmente a scaricare di fatica il tanto amato main thread. Purtroppo e troppo spesso non sono sfruttati però quanto si dovrebbe.

I servizi di remote browser quanto costano?
I remote browser come Mighty (https://www.mightyapp.com/download) hanno comunemente una formula con fee mensile (per Mighty intorno ai 35$/mese) mentre per i servizi di RBI i prezzi sono diversi tra loro e spesso sono inclusi in pacchetti più ampi come quelli di Cloudflare (https://www.cloudflare.com/it-it/plans/zero-trust-services/#overview)

Quali azioni o procedure hai identificato come problematiche o non eseguibili sui browser cloud che sono invece operabili nei browser tradizionali?
In merito ai remote browser (Mighty per capirci) vengono proposti come assolutamente identica come esperienza (ma non ci metterei la mano sul fuoco), mentre i remote browser utili per la RBI non sono di certo adatti ad esperienze troppo ricche o prestanti, dato il potenziale delay e all'epurazione che spesso viene fatta sulla potenziale superficie d'attacco (uno su tutti il caro JS)