Seguretat

Navegació

Seguretat

Canigó – Guia per a aplicacions

Aquesta pàgina explica com s’aplica la seguretat a EventHub i què ha de fer una aplicació per complir els requisits d’accés, autenticació i protecció de dades.

1. Principis de seguretat a EventHub

• Mínim privilegi: només els accessos estrictament necessaris.
• Separació per entorn: INT, PRE i PRO són independents.
• Identitat per aplicació: no es comparteixen credencials.
• Govern centralitzat: validació per part de l’Oficina EventHub.
• Traçabilitat i auditoria d’accessos i canvis.

2. Identitat i autenticació

Clients Kafka

• Cada aplicació disposa d’un o diversos Clients Kafka.
• Un client Kafka representa:
  • una aplicació,
  • un tipus d’ús (producer, consumer, connector, stream),
  • un únic entorn.

❌ No està permès:

• Reutilitzar clients entre aplicacions.
• Utilitzar el mateix client en diversos entorns.
• Compartir credencials.

Mecanisme d’autenticació: OAuth

L’autenticació a EventHub es realitza mitjançant OAuth (OAUTHBEARER) en tots els entorns. No es permet l’ús d’altres mecanismes d’autenticació per a noves integracions.

3. Configuració OAuth per a aplicacions

Pas 1. Sol·licitar credencials OAuth

Cada aplicació ha de disposar de les seves pròpies credencials OAuth. No es permet reutilitzar credencials entre aplicacions.

Per obtenir les credencials:

1. Obrir un tiquet a ACOGICAR a JIRA sol·licitant un nou client OAuth contra Keycloak Cloud.
2. Indicar al tiquet:
   • Client ID: ha de coincidir amb el nom del client Kafka (ex: a1234-crm).
   • Tipus de grant: client_credentials.
   • Entorn destí: INT/PRE o PRO.
3. El resultat serà un client_id i un client_secret.

En cas de no disposar de permisos a ACOGICAR, obrir tiquet Remedy: “Gestió accés d’usuaris”.

Pas 2. Obrir connectivitat

L’aplicació ha d’obrir connectivitat contra el clúster i el port OAuth de l’entorn corresponent:

Pas 3. Configurar l’aplicació Kafka

Les següents propietats són comunes a productors i consumidors:

#Broker
## Protocol de seguretat
security.protocol=SASL_SSL
sasl.mechanism=OAUTHBEARER
sasl.login.callback.handler.class=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginCallbackHandler
session.timeout.ms=45000
## URL del token endpoint (ajustar segons entorn)
### INT / PRE:
sasl.oauthbearer.token.endpoint.url=https://preproduccio.autenticaciogicar5.extranet.gencat.cat/realms/gicar-ad/protocol/openid-connect/token
### PRO:
sasl.oauthbearer.token.endpoint.url=https://autenticaciogicar5.extranet.gencat.cat/realms/gicar-ad/protocol/openid-connect/token
## Credencials
sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
  clientId='<client_id>' \
  clientSecret='<client_secret>';
## Truststore
ssl.truststore.location=<path_al_truststore.jks>
ssl.truststore.password=<contrasenya_truststore>

#Schema Registry
## Protocol de seguretat
security.protocol=SSL
## Credencials (sol·licitar a l'Oficina EventHub)
basic.auth.credentials.source=USER_INFO
basic.auth.user.info=<usuari>:<contrasenya>
## Truststore
schema.registry.ssl.truststore.location=<path_al_truststore.jks>
schema.registry.ssl.truststore.password=<contrasenya_truststore>

Verificació de token

Si hi ha problemes d’autenticació OAuth, es pot verificar el token obtingut a jwt.io. El camp azp del token ha de coincidir amb el principal (client) sobre el qual s’han configurat els permisos.

4. Autorització i permisos (RBAC)

L’accés a EventHub es controla mitjançant RBAC.

Recursos protegits

• Topics.
• Consumer groups.
• Cluster Links i replicacions.

Tipus de permisos habituals

• WRITE sobre topics (productors).
• READ sobre topics (consumidors).
• READ sobre consumer groups.

Regles clau:

• Els permisos es concedeixen per prefix, derivat del nom del client.
• Tot permís addicional ha d’estar justificat i validat.
• Els permisos es defineixen per entorn.
• Per accedir a topics d’altres projectes → pestanya Permisos_Cross de la plantilla.

5. Seguretat de les dades

En trànsit

• Totes les comunicacions amb EventHub estan xifrades (SSL/TLS).
• No es permet trànsit en clar entre aplicacions i la plataforma.

En repòs

• Les dades s’emmagatzemen conforme als estàndards corporatius de xifratge.
• La retenció de dades està limitada per la configuració del topic.

6. Seguretat i schemas

• L’ús de Schema Registry forma part de la seguretat de la dada.
• Els schemas eviten dades mal formades, redueixen errors d’integració i protegeixen els consumidors davant canvis no controlats.
• No es permeten schemas incompatibles sense validació.
• La compatibilitat per defecte és BACKWARD.

7. Seguretat en Connectors i Stream Processing

Connectors

• S’executen amb un Client Kafka específic.
• Només accedeixen als topics necessaris.
• No es permeten connectors genèrics amb permisos amplis.

Stream Processing (ksqlDB / Flink)

• Cada flux o job té identitat i permisos propis.
• L’accés als topics d’entrada i sortida està controlat per ACLs.

8. Seguretat en la replicació

Cluster Linking

• La seguretat entre clústers és gestionada per la plataforma.
• Els enllaços estan governats i auditats.

Replicator

• S’executa com un Connector.
• Hereta totes les regles de seguretat de Kafka Connect.

9. Gestió de canvis i auditoria

S’auditen:

• Altes, canvis i baixes de clients Kafka.
• Canvis de permisos (ACLs).
• Altes i modificacions de recursos crítics.

En PRE i PRO:

• Els canvis rellevants requereixen CRQ.

10. Renovació de certificats (entorns amb mTLS legacy)

Com saber si el teu entorn utilitza mTLS o OAuth?
Comprova la configuració del connector existent: si conté ssl.keystore.location o fa referència a un fitxer .jks, utilitza mTLS. Si conté sasl.mechanism=OAUTHBEARER, utilitza OAuth.
En cas de dubte, contacta amb l’Oficina EventHub abans de continuar.
Per a noves integracions, sempre s’utilitza OAuth — consulta la secció 3 d’aquesta mateixa pàgina.

En entorns que encara utilitzen mTLS (certificats JKS), l’aplicació és responsable de renovar el seu certificat abans que caduqui.

Qui genera el certificat

Validació del certificat JKS

Abans d’enviar el JKS a l’Oficina, cal verificar:

• Que conté 4 nivells de certificats (cadena completa).
• Que les dates de caducitat són correctes.
• Que la contrasenya és la mateixa que l’actual (consultable a la configuració del connector existent).

Es pot verificar amb eines com KeyStore Explorer o amb keytool:

keytool -list -v -keystore <fitxer.jks> -storepass <password>

Procés de renovació

1. L’aplicació genera el nou JKS.
2. L’envia a l’Oficina EventHub.
3. L’Oficina obre un tiquet per pujar-lo als Connect de l’entorn corresponent a la ruta /opt/confluent/certs/.
4. Un cop pujat, els connectors que utilitzen el certificat el carreguen automàticament (pot requerir reinici).

⚠️ Recomanació: migrar a OAuth per evitar la gestió manual de certificats. Consulteu la secció de configuració OAuth d’aquesta mateixa pàgina.

11. Responsabilitats de l’aplicació

L’aplicació és responsable de:

• Protegir les seves credencials.
• Utilitzar únicament els permisos concedits.
• No exposar dades sensibles sense validació.
• Notificar incidents de seguretat.
• Sol·licitar la baixa d’accessos en desús.

12. Errors habituals (evita’ls)

• Compartir credencials entre equips.
• Sol·licitar permisos excessius “per si de cas”.
• Utilitzar el mateix client Kafka en diversos entorns.
• Ignorar l’impacte dels canvis de schema.
• Mantenir accessos que ja no s’utilitzen.
• No obrir la connectivitat al port OAuth abans de provar.

13. Documentació de referència

• Plantillas_Solicitud_EventHub
• Ús de Clients Kafka
• Documentació OAuth Confluent

I ara què?

• -> Estàndards i validació
• -> Autoservei governat
• -> Canvi i desplegament