Hola, el meu nom és René Serral, tinc 20 anys d'experiència donant classes
aquí a la Facultat d'Informàtica de Barcelona en l'àrea de xarxes de
computadors, sistemes operatius, ciberseguretat i cloud.
El tema que tractarem avui és el tema de DevSecOps, que és un terme que ha
començat a estar de moda darrerament, que bàsicament intenta ajuntar tres
mons diferents.
El DevOps, que ve de desenvolupament i operacions, però tenint en compte
la seguretat.
La idea principal que tenim en aquest tipus de forma de fer, perquè al
final és més una filosofia que una tecnologia en si, és intentar donar
consciència de la seguretat en el tema de DevSecOps.
I per què ho volem fer, això? Bàsicament el que succeeix és que els
DevOps, que són els enginyers i enginyeres que es dediquen a
transformar la infraestructura en codis, sobretot en entons cloud,
molts cops no tenen en compte la seguretat i després això pot portar
bastants problemes.
Llavors, el que porta sobre la part de seguretat, que és el que veurem en
aquesta petita introducció al tema, és com podem nosaltres millorar tota
la tasca d'un desplegament dins del cloud automàtic, però ficant-hi bones
pràctiques de ciberseguretat al mig.
Llavors, l'automatització ja la tenim, s'assumeix que tenim un
sistema que és capaç de desplegar de forma automàtica o semiautomàtica
tota l'infraestructura necessària i nosaltres a sobre hi posarem nocions
del secure software life development cycle, que bàsicament són les bones
pràctiques que tenim des del punt de vista del desenvolupament clàssic
però aplicats en aquest nou concepte.
Per poder fer això, els DevSecOps ja fa molts anys que tenen tecnologies
molt interessants, amb Git, per exemple, que ens permeten
automatitzar a la hora que fem canvis a la nostra infraestructura,
automatitzar una sèrie d'experiments i de testos que ens portin a un punt
on intentem que la intervenció humana sigui mínima.
Llavors, cada vegada que fem un canvi, nosaltres el que farem
bàsicament és verificar que aquest canvi no trenca res de la nostra
infraestructura. Això és molt important perquè evitem regressions,
o sigui errors que tornen a passar quan havíem passat abans i els havíem
arreglat, evitem errors o bugs causats per humans moltes vegades i
sobretot tenim una infraestructura molt més robusta.
Llavors, el que farem amb el DevSecOps és afegir-hi la capa de
seguretat en això, que bàsicament, com us deia abans, seran una sèrie de
bones pràctiques, serà una forma de fer que garantirà que per defecte la
seguretat del sistema es proporciona i ens donarà un entorn molt més
cibersegur.
Com ho fem això normalment? En polítiques de permisos mínims, que
bàsicament significa que jo el que intentaré sempre és tenir una
infraestructura que per defecte no permeti fer una acció que no estava
preparada.
Llavors, això es diu Deny by default, que la idea que tenim aquí és, jo
intento fer una acció com un usuari, a no ser que el sistema digui
explicitament que es pot fer aquesta acció, no la permetré.
D'acord? Això és contraposat al que teníem històricament, que es feia al
contrari. Històricament, en el desenvolupament de software i amb els
DevOps, el que es feia típicament és, jo permeto tot i denego només les
coses que sé que no s'han de poder fer.
Això es diu en blacklists, d'acord? Aquestes blacklists tenen el greu
problema que si la meva infraestructura no està ben pensada,
com per defecte permeto les accions, això vol dir que les accions que jo
no tenia pensades davant mà, es podran realitzar.
Per tant, implica fer una selecció de coses que no es poden fer molt més
exhaustiva, el qual és un error.
Llavors, des del Zero Trust i amb la vinguda dels permisos mínims, que és
en el que ens basarem sempre per a fer aquestes accions, doncs li
canviem la truita.
El que farem és treballar en whitelists. Què vol dir això? Que per
defecte denego tot i després només permetré les coses que jo
explicitament he programat que es poden fer.
Quin impacte té això? Que si a alguna cosa s'ha escapat, per defecte no es
podrà fer. Quin problema té això a la pràctica?
Bé, que és bastant més complicat d'implementar, perquè haig de tenir en
compte molts més factors.
I al principi, durant la corba d'aprenentatge d'aquestes tecnologies,
és molt clàssic que els usuaris i els propis desenvolupadors es queixin que
les coses no funcionen per manca de permisos.
Llavors, l'objectiu nostre serà configurar les bones pràctiques i
tenir unes bones guies perquè tot això sigui menys complexe
d'implementar a la pràctica.
Llavors, per una banda, tenim el Git, que ho veurem. Tenim el Secure
Software Development Cycle, que també ho veurem.
I després tenim, junt amb tot això, els pipelines que van lligats a Git.
El pipeline no deixa de ser les validacions que us deia abans.
O sigui, la meva idea serà que quan jo faig un canvi en aquesta
infraestructura, automàticament, abans d'acceptar aquell canvi,
comprovo que aquell canvi no trenca res del que jo havia fet prèviament.
Aleshores, aquests pipelines es diuen CICD, Continuous Integration and
Continuous Deployment, que bàsicament ens automatitzen tot aquest procés i
ens el fan molt més senzill.
Aleshores, això què voldrà dir? Que quan jo vull ficar una nova versió
del meu producte a producció, o sigui, que es fiqui al mercat, abans
de poder entrar al mercat,
obligaré a passar una sèrie de proves automàtiques i llavors automàticament
el sistema, en el cas que tot passi i tot funcioni correctament,
automàticament es desplegarà dins de la meva infraestructura i tindrà una
nova versió amb zero intervenció humana.
Evidentment, això és el nostre objectiu final, és difícil
d'aconseguir, però normalment durant el procés el que farem és
automatitzar a poc a poc diverses parts d'aquest pipeline
per aconseguir arribar, com us deia, al punt aquest de desplegament
automàtic sense intervenció humana.
I això és tot. Moltes gràcies.