Desenvolupament d'apps en entorns Cloud: aspectes clau pel que fa a seguretat

Línies mestres

Les pràctiques i tecnologies de desenvolupament modernes (CI/CD, contenidors, serverless, etc.) requereixen un enfocament integrat amb capacitats que ofereixin una protecció connectada al llarg del cicle de vida de l'aplicació, així com la garantia que els serveis cloud compleixen amb les millors pràctiques de seguretat mentre permeten que els desenvolupadors treballin, amb múltiples i exhaustius controls de seguretat per protegir davant de vulnerabilitats, filtracions, atacs de malware i infraccions de compliment normatiu.
Aquests serien alguns dels aspectes essencials a tenir en compte:

• Seguretat en la canalització: És un pas previ i fonamental per garantir la seguretat. És recomanable realitzar una contínua anàlisi de logs i imatges de contenidors, incloent-hi aquelles localitzades en instàncies Open Source, així com escanejats exhaustius de la canalització CI/CD.
• Protecció d'aplicacions: L'automatització de la seguretat ha de permetre la protecció dels processos de desenvolupament davant de les principals amenaces per a aplicacions en servidors, APIs, contenidors, plataformes serverless, etc.
• Protecció del sistema operatiu del host. En general, tots els contenidors comparteixen un mateix kernel, per la qual cosa serà essencial la seva protecció davant de vulnerabilitats i atacs en la capa del host.
• Seguretat en l'emmagatzematge. El sistema ha d'analitzar qualsevol tipus d'arxiu en cerca de malware i integrar la seguretat en workflows personalitzats amb suport per a tot tipus de plataformes d'emmagatzematge cloud.
• Protecció de contenidors. També en aquest apartat és recomanable un nivell màxim de control sobre esdeveniments i notificacions per atendre els requisits de seguretat i compliment normatiu i seguretat, incloent-hi una monitorització exhaustiva del trànsit en els contenidors.
• Seguretat en els processos de DevOps. La integració d'APIs específiques permet millorar els cicles de desenvolupament i reduir els temps de lliurament, però també és un aliat per reduir els punts de contacte i el factor humà.
• Seguretat de la xarxa: És cert que aquest apartat inclou nombrosos elements per a la protecció del trànsit de xarxa: firewalls, sistemes de detecció d'intrusions, monitorització, gestió d'actius i components... L'objectiu és reduir al màxim la superfície d'atac.
• Seguretat Open Source. Un altre aspecte fonamental, especialment si tenim en compte que una gran part del codi que circula és de codi obert. Serà necessari tenir visibilitat sobre les vulnerabilitats dels entorns open source, incloent-hi la gestió de riscos de llicència.

Codificació segura: Principals riscos segons l'OWASP.

L'OWASP Top 10 és un document de conscienciació estàndard per a desenvolupadors i seguretat d'aplicacions web, reconegut mundialment pels desenvolupadors com el primer pas cap a una codificació més segura.

Les empreses han d'adoptar aquest document i començar el procés de garantir que les seves aplicacions web minimitzin aquests riscos. Utilitzar el OWASP Top 10 és potser el primer pas més efectiu per canviar la cultura de desenvolupament de programari de l'organització. A continuació es mostra cadascun d'aquests riscos:

• A01. Trencament del control d'accés. Permet als atacants comprometre les dades mitjançant l'obtenció d'accés amb privilegis o l'apropiació de comptes. El 94% de les aplicacions provades van presentar aquest tipus de problema.
• A02. Errors criptogràfics. Són errors relacionats amb el xifrat que sovint condueixen a l'exposició de dades confidencials o a la presa de control dels sistemes. Solen ser més un símptoma que una causa arrel.
• A03. Injecció. Aquesta categoria (injeccions SQL, injeccions JavaScript) fa referència a la càrrega de codi maliciós en l'aplicació presenta la segona major quantitat de casos. El Cross-site Scripting és ara part d'aquesta categoria.
• A04. Disseny insegur. Una nova categoria respecte a informes anteriors que fa referència als riscos relacionats amb fallades en el disseny. OWASP recomana elements com threat modeling, patrons i arquitectures de referència.
• A05. Errors de configuració. Cada cop més comuns per l'ús del núvol com a entorn de desenvolupament i el desenvolupament amb imatges de contenidors. El 90% de les aplicacions provades per l'OWASP van mostrar algun tipus d'error d'aquest tipus.
• A06. Fallades en els components. Un problema conegut, però que costa avaluar. Normalment, aquestes vulnerabilitats provenen de l'ús de marcs o biblioteques desactualitzats que són fàcils d'explotar.
• A07. Errors d'identificació i autenticació. Mala gestió de les sessions, contrasenyes dèbils o no limitar la taxa d'intents de login continuen suposant un problema, però menys crític per la cada vegada major disponibilitat de marcs estandarditzats.
• A08. Falles d'integritat en les dades i el programari. Una categoria afegida en l'últim informe que fa referència a les vulnerabilitats en el programari, dades crítiques i canalitzacions de CI/CD.
• A09. Fallades de registre i monitorització. Les fallades en aquesta categoria poden afectar la capacitat de la seva empresa per detectar i respondre davant possibles bretxes, ja que dificulta la visibilitat, les alertes sobre incidents i l'anàlisi forense.
• A10. Falsificació de sol·licituds del costat del servidor. Afegida en l'últim informe, és un problema relativament mesurable i monitoritzable. Passa quan els atacants fan que els servidors realitzin sol·licituds no autoritzades.

Seguretat en cada fase del procés

La definició de nivells acceptables de seguretat i privacitat des del principi de cada projecte ajuda els equips de DevOps a comprendre els riscos, identificar i corregir errors durant el desenvolupament i aplicar aquests nivells al llarg de tot el projecte.

1. Disseny

Durant aquesta fase caldrà plantejar qüestions fonamentals de seguretat i privacitat, anticipant tots els vectors d'atac i vulnerabilitats. La definició dels nivells acceptables de seguretat i privacitat al principi d'un projecte ajuda un equip a comprendre els riscos associats a problemes de seguretat, corregir fallades de seguretat durant el desenvolupament i aplicar els nivells adequats de seguretat i privacitat al llarg de tot el projecte.

2. Implementació

Abans d'inserir el codi en el repositori, serà necessari realitzar revisions per augmentar la qualitat general i reduir el risc d'errors. L'anàlisi de codi font és un element clau en la revisió de codi estàtic per trobar possibles vulnerabilitats en el codi que no s'està executant. Així mateix, serà necessari prevenir els atacs per injecció amb la validació d'entrades per evitar que les dades amb format incorrecte es conservin en la base de dades o desencadenin errors en altres components. La codificació de sortides proporciona defenses per nivells per augmentar la seguretat del sistema com un tot.

També serà essencial separar les dades de producció, i no utilitzar-les per desenvolupament, proves o qualsevol altre fi diferent de l'establert. I, per descomptat, seguir altres bones pràctiques com l'anonimització per a tot el procés, o evitar l'emmagatzematge en memòria cau de contingut confidencial.

3. Comprovació

Aquesta fase passa per verificar que el codi compleix els principis de seguretat i privacitat que es van establir en les fases anteriors. Inclou, per exemple, la cerca i correcció de vulnerabilitats en les dependències de l'aplicació.

Una altra bona pràctica és provar l'aplicació en estat operatiu. Les proves dinàmiques de seguretat d'aplicacions (DAST, per les seves sigles en anglès) permeten analitzar-les mentre s'executen per buscar vulnerabilitats com danys en la memòria, configuracions de servidor no segures, atacs de script entre llocs, injecció de codi, etc. Les proves de vulnerabilitats, per la seva banda, consisteixen a induir un error introduint dades aleatòries o amb format incorrecte, cosa que ajuda a revelar possibles problemes de seguretat abans del pas a producció.

Per últim, la revisió de la superfície d'atac després de completar el codi ajudarà a garantir que s'han tingut en compte els canvis en el disseny i la implementació, i que els nous vectors d'atac s'han revisat i mitigat. Per la seva banda, les proves de penetració (o pentesting) són atacs simulats per trobar les vulnerabilitats de seguretat i tots els sistemes que podrien tenir accés a les aplicacions, la seva funcionalitat i les seves dades.

DevSecOps: una nova forma de concebre el desenvolupament

D'acord amb un informe publicat el 2020, el 92% dels professionals de TI no creuen que la seva organització estigui preparada per protegir els serveis de núvol públic. Això succeeix perquè no només depèn de la seguretat com a part de l'equip de desenvolupadors i operadors, també ho és la pròpia infraestructura de seguretat.

DevSecOps és la pràctica d'integrar les proves de seguretat en cada etapa del procés de desenvolupament de programari. Inclou eines i processos que fomenten la col·laboració entre els desenvolupadors, els especialistes en seguretat i els equips d'operacions per crear un programari que sigui eficient i segur.

Els beneficis són múltiples i perfectament visibles: reducció en el temps de lliurament, detecció primerenca i automàtica de vulnerabilitats, desenvolupament de noves característiques de forma segura, millores en la col·laboració i la comunicació entre equips i garantia de compliment normatiu, entre altres.

En definitiva, avui dia, el núvol és un espai preferent a l'hora de crear aplicacions i serveis, i mètodes com el DevSecOps són fonamentals per al funcionament de la infraestructura i seguretat de la tecnologia a les empreses. Però només una estratègia integral i que es posi en pràctica des de l'inici de cada projecte permetrà agilitzar els temps, reduir els costos i garantir la seguretat en el desenvolupament.