Una integració entre una botiga en línia, un CRM, un ERP o una eina de suport acostuma a rebre una autorització descrita de manera massa àmplia: «accés a comandes» o «accés al CRM». Aquesta simplificació dificulta saber què necessita realment el connector i pot mantenir disponibles funcions o dades que no formen part de la seva feina.
La matriu de permisos per a API converteix aquest accés genèric en decisions concretes i revisables. La seva utilitat no es limita a l'equip tècnic: operacions pot validar el procés, negoci pot aprovar les accions sensibles i els proveïdors poden conèixer els límits de la seva intervenció. L'objectiu és que cada actor, humà o automàtic, accedeixi únicament a les operacions, els registres i els camps necessaris.
El problema d'autoritzar una eina completa
Estar autenticat identifica una persona, un procés o un compte tècnic, però no determina per si mateix què pot fer. L'autorització ha de respondre, com a mínim, si aquest actor pot executar una acció concreta i sobre quin recurs. Per exemple, un connector que crea contactes des d'un formulari no necessita necessàriament exportar tots els contactes, canviar propietaris, suprimir registres ni consultar informació interna. [2]
També cal distingir el permís sobre una funció del permís sobre un objecte concret. Que un portal permeti consultar comandes no implica que qualsevol client pugui consultar qualsevol comanda: el sistema ha de comprovar que el registre sol·licitat pertany a la seva empresa o al seu compte. OWASP identifica la manca d'aquesta comprovació a nivell d'objecte com un risc que pot conduir a l'exposició, la modificació o l'eliminació no autoritzada de dades. [1]
Què ha d'incloure una matriu de permisos per operació
Una matriu és un inventari estructurat de decisions d'accés. Cada fila representa una necessitat operativa, no un rol genèric com «administrador» o «accés complet». Pot començar amb una integració crítica, com ara web–CRM, comerç electrònic–ERP o portal de clients–suport, i ampliar-se després a la resta de l'ecosistema. El valor rau a fer visibles les excepcions abans de convertir-les en credencials o regles tècniques.
Com a plantilla mínima, incloeu el sistema o la integració; l'actor; el recurs; l'operació; l'abast; els camps permesos i exclosos; el mètode d'autenticació i la credencial associada; les condicions addicionals; la persona responsable; la data de revisió, i l'esdeveniment que s'ha de registrar. Entre les operacions convé diferenciar llegir, crear, actualitzar, cancel·lar, aprovar, exportar i suprimir, perquè el seu impacte no és equivalent.
- Actor: empleat, client, proveïdor, procés automàtic o compte de servei.
- Abast: dades pròpies, una empresa determinada, una unitat de negoci o dades internes.
- Condició: per exemple, només comandes assignades, només documents en un estat concret o aprovació prèvia per exportar.
Exemple hipotètic d'una integració web–CRM
Exemple hipotètic: una empresa connecta el formulari de sol·licitud comercial del seu web amb el CRM. El compte tècnic del formulari pot crear un contacte i un client potencial, però només amb nom, correu electrònic, empresa, telèfon i missatge. No pot llegir contactes existents, descarregar llistats, modificar el propietari comercial, consultar notes internes ni suprimir registres. El responsable de negoci valida que aquests camps són suficients per atendre la sol·licitud.
La mateixa matriu ha de descriure l'abast de les dades. Si el CRM organitza els clients per filials, el procés automàtic hauria de crear registres únicament a la unitat assignada, no a totes. Si necessita detectar duplicats, pot requerir una comprovació limitada i registrada, en lloc d'un accés de lectura global. Aquesta precisió evita que una necessitat legítima es tradueixi en una credencial amb capacitats innecessàries.
Cinc regles per convertir la matriu en controls reals
Primer, apliqueu la denegació per defecte: tota operació que no estigui autoritzada expressament s'ha de rebutjar. Segon, comproveu al servidor i en cada sol·licitud tant l'acció com l'objecte sol·licitat; no n'hi ha prou d'ocultar un botó a la interfície ni de validar el permís només quan s'emet un testimoni. Tercer, separeu els comptes de persones dels comptes tècnics per poder limitar, revisar i retirar-ne les capacitats de manera independent. [2]
Quart, limiteu cada compte d'integració als recursos, les operacions i els camps que requereix el procés. Cinquè, establiu revisions periòdiques i revisions desencadenades per canvis rellevants, com ara la baixa d'un proveïdor, un canvi de funcions, un endpoint nou o una automatització substituïda. Mantenir el cicle de vida dels comptes inclou registrar altes, canvis, habilitacions i baixes, així com desactivar comptes que ja no corresponguin a una persona o necessitat vigent. [4]
- Eviteu claus compartides entre proveïdors o automatitzacions diferents.
- Assigneu un responsable de negoci per als permisos sensibles, encara que tecnologia implementi el control.
- Registreu els canvis de permisos i les accions rellevants dels comptes tècnics per facilitar-ne la revisió.
Com validar i mantenir la matriu
Abans de publicar canvis, convertiu la matriu en casos de prova. Amb autorització expressa, abast definit i preferiblement comptes o dades de prova, confirmeu que cada acció permesa funciona i que cada acció no concedida es rebutja. Comproveu tant operacions de consulta com de modificació, i proveu rols o comptes amb el mínim privilegi. La revisió ha de ser defensiva, planificada i limitada a l'entorn i als sistemes autoritzats. [3]
Una revisió útil no busca demostrar que el sistema «és segur» en termes absoluts. Busca detectar diferències entre el procés aprovat, la matriu documentada i el comportament real de l'API, el tauler administratiu i el web. Si una regla és diferent entre canals, si un compte tècnic té permisos d'administrador per precaució o si un connector pot exportar dades que no utilitza, convé corregir el disseny i tornar a validar el canvi. [1] [3]
Preguntes freqüents
Quina diferència hi ha entre autenticació i autorització en una API?
L'autenticació verifica la identitat de qui fa una sol·licitud, com ara un usuari o un compte d'integració. L'autorització decideix quina operació pot executar aquesta identitat, sobre quin recurs, amb quin abast i en quines condicions. Totes dues són necessàries.
Cada integració necessita un compte propi?
En general, separar els comptes tècnics per integració facilita limitar permisos, registrar activitats i retirar accessos quan un procés canvia o deixa d'utilitzar-se. Un compte compartit pot dificultar l'atribució d'accions i l'aplicació de límits específics.
Amb quina integració convé començar la matriu?
Comenceu per una integració crítica o que tracti dades rellevants, com ara la connexió entre web i CRM, botiga i ERP, o portal de clients i suport. Documenteu les operacions reals, valideu els límits amb negoci i tecnologia, i utilitzeu el resultat com a model per a les altres integracions.