Salta el contingut

Gestió de Credencials i PKI

Proposta didàctica

En aquest bloc treballem el RA3: Administra credencials d'accés a sistemes informàtics aplicant els requisits de seguretat establerts.

Criteris d'avaluació

  • CA3.1 Identifica i classifica els tipus de credencials d'accés als sistemes.

  • CA3.2 Utilitza certificats digitals per a l'accés segur via SSH.

  • CA3.3 Valida la correctesa de certificats web (cadena de confiança, data de caducitat, SAN).

  • CA3.4 Compara certificats vàlids i invàlids identificant-ne les diferències.

  • CA3.5 Configura un servidor RADIUS per a l'autenticació centralitzada de xarxa.

Continguts de referència

  1. Gestors de contrasenyes corporatives
    • 1.1 Bitwarden (codi obert, auto-allotjat)
    • 1.2 HashiCorp Vault (secrets management)
    • 1.3 1Password Teams i Keeper Enterprise
  2. Infraestructura de Clau Pública (PKI)
    • 2.1 Autoritats de Certificació (CA): Root CA, Intermediate CA
    • 2.2 Tipus de certificats: DV, OV, EV
    • 2.3 Revocació: CRL i OCSP
    • 2.4 Let's Encrypt i ACME protocol
  3. Gestió de claus SSH
    • 3.1 Generació de parells de claus (Ed25519, RSA)
    • 3.2 Autoritzed keys i SSH CA
    • 3.3 Ssh-agent i gestió d'identitats
  4. Privileged Access Management (PAM)
    • 4.1 Just-in-time access
    • 4.2 Session recording
  5. Protocols d'autenticació centralitzada
    • 5.1 RADIUS (RFC 2865): arquitectura i protocoles
    • 5.2 TACACS+ (Cisco): comparació amb RADIUS
    • 5.3 Kerberos v5: tickets i TGT
  6. Network Access Control (NAC)
    • 6.1 802.1X: autenticació per port
    • 6.2 EAP: Extensible Authentication Protocol

Questionari inicial

  1. Qué és una credencial d'accés i quins tipus existeixen?
  2. Per qué NO és segur emmagatzemar contrasenyes en un fitxer de text pla?
  3. Qué és un gestor de contrasenyes i quins avantatges ofereix?
  4. Qué és una CA (Autoritat de Certificació) i quin és el seu rol en la PKI?
  5. Quina diferència hi ha entre un certificat DV, OV i EV?
  6. Qué és la cadena de confiança d'un certificat digital?
  7. Per qué un certificat auto-signat NO és de confiança per als navegadors?
  8. Qué és la CRL i l'OCSP i per qué s'utilitzen?
  9. Quina diferència hi ha entre autenticació SSH per contrasenya i per clau pública?
  10. Per qué Ed25519 és preferible a RSA-2048 per a claus SSH?
  11. Qué és RADIUS i en quin escenari s'utilitza?
  12. Quina diferència hi ha entre RADIUS i TACACS+?
  13. Qué és Kerberos i per qué es diu que usa "tiquets"?
  14. Qué és el 802.1X i com s'usa en xarxes WiFi corporatives?
  15. Qué és PAM (Privileged Access Management) i per qué és important?
  16. Qué és HashiCorp Vault i quin problema resol en entorns de DevOps?
  17. Qué és LDAP i com es relaciona amb l'autenticació centralitzada?
  18. Qué és SSO (Single Sign-On) i quin protocol l'implementa habitualment?
  19. Qué és un atac de "Pass the Hash" en autenticació Windows?
  20. Per qué cal rotar les credencials de servei regularment?

Programació d'aula

Sessió Continguts Activitats CAs Treballats
45-48 Gestors de contrasenyes; Bitwarden i Vault Desplegar Bitwarden en Docker CA3.1
49-52 PKI: CA jerarquia, certificats X.509, OpenSSL Crear CA pròpia i emetre certificats CA3.1, CA3.3, CA3.4
53-56 Claus SSH, SSH CA i gestió d'identitats Pràctica claus SSH i accés per certificat SSH CA3.2
57-60 RADIUS, TACACS+ i Kerberos Laboratori FreeRADIUS en Docker CA3.5
61-64 HashiCorp Vault: secrets, dynamic credentials Desplegament Vault + secrets dinàmics CA3.1
65-66 PAM, NAC 802.1X i avaluació bloc 3 Qüestionari i cas pràctic integrador CA3.5

Gestors de Contrasenyes Corporatives

El problema de la gestió de contrasenyes

Una organització típica gestiona centenars o milers de credencials: comptes d'administrador de sistemes, APIs keys, contrasenyes de bases de dades, certificats, tokens de servei... Sense una solució centralitzada, les credencials acaben:

  • En documents Word o Excel sense xifrat
  • En fitxers .env en repositoris de codi (problemàtica de secrets en git)
  • Compartides per correu electrònic o missatgeria
  • Reutilitzades entre sistemes per facilitar la memòria
  • Sense rotació regular

Bitwarden: gestor de codi obert

Bitwarden és l'única solució de gestor de contrasenyes corporativa completament de codi obert, amb opció d'auto-allotjament:

# docker-compose.yml per desplegar Bitwarden (Vaultwarden)
services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: bitwarden-NOMCOGNOM
    environment:
      WEBSOCKET_ENABLED: "true"
      SIGNUPS_ALLOWED: "false"          # Desactiva registre públic
      ADMIN_TOKEN: "token_super_segur"  # Accés al panel admin
      DOMAIN: "https://vault.empresa.cat"
    volumes:
      - ./vaultwarden-data:/data
    ports:
      - "8080:80"
      - "3012:3012"
    restart: unless-stopped

# Iniciar el servei
docker-compose up -d

# Crear usuaris inicials via API admin
curl -X POST https://vault.empresa.cat/admin/users/invite \
  -H "Authorization: Bearer token_super_segur" \
  -d '{"email": "usuari@empresa.cat"}'

HashiCorp Vault: secrets management empresarial

HashiCorp Vault és una solució avançada de gestió de secrets pensada per a entorns de DevOps i infraestructures complexes. Va més enllà d'un gestor de contrasenyes: genera credencials dinàmiques, gestiona certificats PKI i xifra dades sensibles.

Funcionalitats clau: - Secrets estàtics: Emmagatzemar secrets clau-valor xifrats - Secrets dinàmics: Generar credencials de base de dades temporals sota demanda - PKI Engine: Actuar com a CA per emetre certificats X.509 - Transit Engine: Xifrar/desxifrar dades sense que Vault accedeixi als plaintext - Audit Log: Registre complet de qui ha accedit a cada secret i quan

# Desplegament de Vault en mode dev (només per proves)
docker run --cap-add=IPC_LOCK \
  -e VAULT_DEV_ROOT_TOKEN_ID=dev-token \
  -p 8200:8200 \
  --name vault-NOMCOGNOM \
  hashicorp/vault:latest

# Escriure un secret
export VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_TOKEN='dev-token'

vault kv put secret/empresa/db \
  username="admin" \
  password="P@ssw0rd_Segur_2024"

# Llegir el secret
vault kv get secret/empresa/db

# Generar credencials dinàmiques per a PostgreSQL
vault secrets enable database
vault write database/config/postgresql \
  plugin_name=postgresql-database-plugin \
  allowed_roles="app-role" \
  connection_url="postgresql://{{username}}:{{password}}@db:5432/empresa"

Bones pràctiques de gestió de secrets

  • Mai commitar secrets a un repositori Git. Usa .gitignore i eines com git-secrets o trufflehog per detectar filtracions.
  • Usa variables d'entorn injectades en temps d'execució, no en fitxers de configuració.
  • Rota les credencials regularment (especialment les de servei).
  • Usa credencials dinàmiques (Vault) quan sigui possible: viuen poc temps i s'auto-destrueixen.

Miniactivitat

Instal·la la versió de línia de comandes de Bitwarden (bw): 

npm install -g @bitwarden/cli
bw login
bw list items | jq '.[].name'
Experimenta creant un element, generant una contrasenya segura i exportant el vault. Reflexiona sobre els avantatges respecte a desar contrasenyes en un document Word.

Infraestructura de Clau Pública (PKI)

Arquitectura PKI

Una PKI (Public Key Infrastructure) és el conjunt de polítiques, procediments, maquinari, programari i persones necessàries per crear, gestionar, distribuir, usar, emmagatzemar i revocar certificats digitals.

graph TB
    RootCA["🏛️ Root CA\n(Autoritat Arrel)\nClau arrel guardada offline\ncertificat auto-signat de 20-30 anys"]

    IntCA1["🏢 CA Intermèdia - Servidors\nEmissió de certificats TLS\nper servidors web i aplicacions"]
    IntCA2["🏢 CA Intermèdia - Usuaris\nEmissió de certificats\nper a empleats (S/MIME, VPN)"]
    IntCA3["🏢 CA Intermèdia - Dispositius\nEmissió de certificats\nper a dispositius de xarxa"]

    Cert1["📄 Certificat TLS\nwww.empresa.cat"]
    Cert2["📄 Certificat TLS\napi.empresa.cat"]
    Cert3["📄 Certificat Usuari\njoan@empresa.cat"]
    Cert4["📄 Certificat Switch\nswitch-01.empresa.cat"]

    RootCA -->|signa| IntCA1
    RootCA -->|signa| IntCA2
    RootCA -->|signa| IntCA3
    IntCA1 -->|signa| Cert1
    IntCA1 -->|signa| Cert2
    IntCA2 -->|signa| Cert3
    IntCA3 -->|signa| Cert4

    style RootCA fill:#cc0000,color:#fff
    style IntCA1 fill:#cc6600,color:#fff
    style IntCA2 fill:#cc6600,color:#fff
    style IntCA3 fill:#cc6600,color:#fff

Creació d'una CA pròpia amb OpenSSL

# === CREACIÓ DE LA CA ARREL ===

# 1. Generar clau privada de la CA (4096 bits RSA o Ed25519)
openssl genrsa -aes256 -out ca-root.key 4096
# o amb Ed25519:
openssl genpkey -algorithm Ed25519 -out ca-root.key

# 2. Crear el certificat auto-signat de la CA (10 anys)
openssl req -new -x509 -days 3650 \
  -key ca-root.key \
  -out ca-root.crt \
  -subj "/C=ES/ST=Catalunya/L=Blanes/O=Institut Sa Palomera/CN=Root CA NOMCOGNOM"

# === EMISSIÓ D'UN CERTIFICAT PER A UN SERVIDOR ===

# 3. Generar clau privada del servidor
openssl genrsa -out servidor.key 2048

# 4. Crear una CSR (Certificate Signing Request)
openssl req -new \
  -key servidor.key \
  -out servidor.csr \
  -subj "/C=ES/ST=Catalunya/O=Empresa/CN=www.empresa.cat"

# Afegir Subject Alternative Names (SANs)
cat > servidor-ext.cnf << 'EOF'
[req_ext]
subjectAltName = @alt_names
[alt_names]
DNS.1 = www.empresa.cat
DNS.2 = empresa.cat
DNS.3 = api.empresa.cat
IP.1 = 192.168.1.10
EOF

# 5. Signar la CSR amb la CA
openssl x509 -req -days 365 \
  -in servidor.csr \
  -CA ca-root.crt \
  -CAkey ca-root.key \
  -CAcreateserial \
  -extfile servidor-ext.cnf \
  -extensions req_ext \
  -out servidor.crt

# 6. Verificar el certificat emès
openssl x509 -in servidor.crt -noout -text | grep -A10 "Validity\|Subject\|Subject Alternative"

Let's Encrypt i el protocol ACME

Let's Encrypt és una CA gratuïta, automatitzada i oberta que ha revolucionat l'adopció de HTTPS. Usa el protocol ACME (Automatic Certificate Management Environment, RFC 8555) per automatitzar el cicle de vida dels certificats.

# Obtenir certificat Let's Encrypt amb certbot (Docker)
docker run --rm \
  -v "/etc/letsencrypt:/etc/letsencrypt" \
  -v "/var/www/html:/var/www/html" \
  certbot/certbot certonly \
  --webroot \
  -w /var/www/html \
  -d www.empresa.cat \
  -d empresa.cat \
  --email admin@empresa.cat \
  --agree-tos \
  --non-interactive

# Renovació automàtica (afegir al cron)
# 0 3 * * * docker run --rm ... certbot/certbot renew --quiet

Revocació de certificats: CRL i OCSP

Si una clau privada es compromet, el certificat s'ha de revocar per avisar als clients que ja no és de confiança:

CRL (Certificate Revocation List): Llista de certificats revocats publicada periòdicament per la CA. Els clients descarreguen la llista i comproven si el certificat hi apareix. Problema: Les CRLs poden ser grans i les actualitzacions no són en temps real (problema de "soft fail").

OCSP (Online Certificate Status Protocol, RFC 6960): Protocol de consulta en temps real: el client pregunta al servidor OCSP si un certificat específic és vàlid. Millora: Respostes en temps real, però depèn de la disponibilitat del servidor OCSP.

OCSP Stapling: El servidor web fa la consulta OCSP per compte del client i inclou la resposta signada en el handshake TLS. Millora la privadesa (el servidor OCSP no sap qui visita el lloc) i el rendiment.

Miniactivitat

Inspecciona el certificat d'un lloc web important (google.com, github.com, gencat.cat):

# Inspecció de certificat amb OpenSSL
echo | openssl s_client -connect google.com:443 -servername google.com 2>/dev/null | \
  openssl x509 -noout -text

# Verificar OCSP
echo | openssl s_client -connect google.com:443 -servername google.com 2>/dev/null | \
  openssl x509 -noout -ocsp_uri

# Verificar la cadena de certificats
echo | openssl s_client -connect google.com:443 -showcerts 2>/dev/null | \
  grep -E "^(depth|verify|subject|issuer)"
Identifica: qui ha emès el certificat, quina és la data de caducitat, quins SANs conté, i si usa OCSP Stapling.

Gestió de Claus SSH

Autenticació per clau pública SSH

L'autenticació SSH per clau pública és molt més segura que per contrasenya: - La clau privada mai surt del client - Immune als atacs de força bruta (matemàticament infactible) - Pot usar passphrase per protegir la clau privada localment - Auditable: se sap exactament quines claus tene accés

# Generar parell de claus Ed25519 (recomanat, segur i eficient)
ssh-keygen -t ed25519 -C "NOMCOGNOM@empresa.cat" -f ~/.ssh/id_ed25519

# O RSA-4096 per compatibilitat amb sistemes antics
ssh-keygen -t rsa -b 4096 -C "NOMCOGNOM@empresa.cat" -f ~/.ssh/id_rsa

# Copiar clau pública al servidor (mètode 1: ssh-copy-id)
ssh-copy-id -i ~/.ssh/id_ed25519.pub usuari@servidor.empresa.cat

# Copiar clau pública al servidor (mètode 2: manual)
cat ~/.ssh/id_ed25519.pub | ssh usuari@servidor.empresa.cat \
  "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

# Connectar per SSH usant la clau (sense contrasenya)
ssh -i ~/.ssh/id_ed25519 usuari@servidor.empresa.cat

# Usar ssh-agent per no introduir passphrase cada vegada
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

SSH CA: Certificats per a SSH

En entorns corporatius grans, gestionar claus SSH individuals és complex. L'alternativa és usar una SSH CA que emet certificats SSH temporals:

# === CONFIGURACIÓ SSH CA ===

# 1. Crear la clau de la CA SSH
ssh-keygen -t ed25519 -f /etc/ssh/ssh_ca -C "SSH CA NOMCOGNOM"

# 2. Configurar el servidor SSH per confiar en la CA
echo "TrustedUserCAKeys /etc/ssh/ssh_ca.pub" >> /etc/ssh/sshd_config
systemctl reload sshd

# 3. Signar la clau pública d'un usuari (vàlid 1 dia, per a l'usuari "joan")
ssh-keygen -s /etc/ssh/ssh_ca \
  -I "joan@empresa.cat" \
  -n joan \                      # principals (usuaris permesos)
  -V +1d \                       # validesa: 1 dia
  ~/.ssh/id_ed25519.pub

# 4. Connectar amb el certificat (l'agent automàticament detecta el cert)
ssh -i ~/.ssh/id_ed25519 joan@servidor.empresa.cat
# El servidor verifica el certificat signat per la CA i permet l'accés

# Verificar un certificat SSH
ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub

Protocols d'Autenticació Centralitzada

RADIUS (Remote Authentication Dial-In User Service)

RADIUS (RFC 2865, 1997) és el protocol estàndard per a l'autenticació centralitzada en entorns de xarxa. Permet que routers, switches, APs WiFi i VPNs deleguïn l'autenticació a un servidor central.

Arquitectura RADIUS:

sequenceDiagram
    participant C as Client (Usuari)
    participant NAS as NAS / Access Point\n(RADIUS Client)
    participant RADIUS as Servidor RADIUS\n(FreeRADIUS)
    participant LDAP as Directori LDAP\n(AD, OpenLDAP)

    C->>NAS: Sol·licitud d'accés (credencials)
    NAS->>RADIUS: Access-Request (usuari, contrasenya xifrada, NAS-IP)
    RADIUS->>LDAP: Consulta d'autenticació
    LDAP->>RADIUS: Resposta (autenticat / denegat)
    RADIUS->>NAS: Access-Accept (amb atributs: VLAN, QoS, timeout)
    NAS->>C: ✅ Accés concedit a la xarxa

Característiques de RADIUS: - Transport: UDP (ports 1812 autenticació, 1813 accounting) - Xifra únicament la contrasenya (amb MD5 + secret compartit) - Suporta atributs extensibles (VSA - Vendor Specific Attributes) - Pot delegar a LDAP, Active Directory o base de dades local - Suporta accounting: registre d'inici/fi de sessió

# Desplegar FreeRADIUS amb Docker
docker run -d \
  --name radius-NOMCOGNOM \
  -p 1812:1812/udp \
  -p 1813:1813/udp \
  -v ./radius-config:/etc/freeradius/3.0 \
  freeradius/freeradius-server:latest

# Testejar autenticació RADIUS
radtest usuari contrasenya localhost 0 secret_compartit

Fitxer de configuració d'usuaris RADIUS (/etc/freeradius/3.0/users):

# Usuari amb VLAN assignada
joan    Cleartext-Password := "contrasenya_segura"
        Tunnel-Type = VLAN,
        Tunnel-Medium-Type = IEEE-802,
        Tunnel-Private-Group-Id = "100"

# Usuari administrador amb accés complet
admin   Cleartext-Password := "admin_password"
        Service-Type = Administrative-User

TACACS+ (Terminal Access Controller Access-Control System Plus)

TACACS+ (Cisco, RFC 8907) és una alternativa a RADIUS dissenyada específicament per a la gestió d'accés a dispositius de xarxa (routers, switches). Diferències clau:

Característica RADIUS TACACS+
Transport UDP TCP (port 49)
Xifrat Només contrasenya Tot el paquet
Separació AAA Combinada Separada (A, A, A)
Orientat a Accés de xarxa Gestió de dispositius
Granularitat Per usuari Per comanda
Vendor Obert Principalment Cisco

Quan usar RADIUS vs TACACS+

  • RADIUS: WiFi corporativa, VPN d'accés remot, autenticació d'usuaris finals.
  • TACACS+: Accés per consola/SSH a routers i switches, control granular de comandaments (quins comandaments pot executar cada administrador).

Kerberos v5

Kerberos (RFC 4120) és el protocol d'autenticació de xarxa usat per Microsoft Active Directory i molts sistemes Unix. Usa una arquitectura de "tiquets" per evitar transmetre contrasenyes per la xarxa.

Conceptes clau: - KDC (Key Distribution Center): Servidor que emet tiquets. Inclou AS (Authentication Service) i TGS (Ticket Granting Service). - TGT (Ticket Granting Ticket): Tiquet temporal (8-10h) que l'usuari rep en autenticar-se inicialment. Permet obtenir tiquets per a serveis específics sense tornar a autenticar-se. - ST (Service Ticket): Tiquet específic per accedir a un servei concret (correu, fitxers, etc.).

sequenceDiagram
    participant C as Client
    participant AS as KDC - Authentication Service
    participant TGS as KDC - Ticket Granting Service
    participant S as Servei (File Server, etc.)

    C->>AS: Petició d'autenticació (nom d'usuari)
    AS->>C: TGT xifrat + clau de sessió
    Note over C: Desxifra amb la contrasenya de l'usuari

    C->>TGS: Petició de Service Ticket (TGT + servei destí)
    TGS->>C: Service Ticket (ST) per al servei
    Note over C: ST xifrat amb la clau del servei destí

    C->>S: Petició d'accés + ST
    S->>S: Desxifra ST amb la seva clau
    S->>C: ✅ Accés concedit (autenticat)
    Note over C,S: Sense contrasenya transmesa!

Network Access Control (NAC) i 802.1X

El protocol 802.1X

IEEE 802.1X és un estàndard d'autenticació basada en port per a xarxes Ethernet i WiFi. Impedeix l'accés a la xarxa fins que el dispositiu no s'ha autenticat correctament.

Actors de 802.1X: - Supplicant: El dispositiu client que vol accedir a la xarxa. - Authenticator: El switch o AP que controla l'accés al port de xarxa. - Authentication Server: El servidor RADIUS que verifica les credencials.

Protocol EAP (Extensible Authentication Protocol) és el mecanisme d'autenticació usat per 802.1X. Existeixen múltiples mètodes EAP:

Mètode EAP Seguretat Requeriments client Ús recomanat
EAP-MD5 Molt baixa Cap certificat No recomanat (llegat)
EAP-TLS Molt alta Certificat al client Entorns corporatius
PEAP-MSCHAPv2 Alta Certificat CA al client WiFi corporativa (Windows)
EAP-TTLS Alta Certificat CA al client Linux/Android corporatiu
EAP-FAST Alta PAC (Cisco) Entorns Cisco 
sequenceDiagram
    participant D as Dispositiu (Supplicant)
    participant SW as Switch/AP (Authenticator)
    participant R as RADIUS Server

    D->>SW: Connexió al port de xarxa
    SW->>D: Port bloquejat - sol·licita identitat (EAP-Request)
    D->>SW: Identitat (nom d'usuari o certificat)
    SW->>R: Access-Request (identitat + EAP data)
    R->>SW: EAP challenge
    SW->>D: EAP challenge
    D->>SW: EAP response (credencials xifrades)
    SW->>R: Access-Request (EAP response)
    R->>SW: Access-Accept (VLAN=100, QoS=...)
    SW->>D: EAP-Success + Port obert a VLAN 100
    D->>D: ✅ Accés a la xarxa empresa

Miniactivitat

Despliega FreeRADIUS amb Docker i configura un client de prova:

# 1. Descarregar la configuració base
docker run -d --name radius-test \
  -p 1812:1812/udp -p 1813:1813/udp \
  freeradius/freeradius-server:latest

# 2. Obtenir els fitxers de configuració
docker cp radius-test:/etc/freeradius/3.0 ./radius-config

# 3. Afegir un usuari de prova al fitxer users
echo 'testuser    Cleartext-Password := "testpassword"' >> ./radius-config/users

# 4. Reiniciar el contenidor amb la configuració nova
docker stop radius-test && docker rm radius-test
docker run -d --name radius-NOMCOGNOM \
  -p 1812:1812/udp -p 1813:1813/udp \
  -v $(pwd)/radius-config:/etc/freeradius/3.0 \
  freeradius/freeradius-server:latest

# 5. Testejar l'autenticació
docker exec radius-NOMCOGNOM \
  radtest testuser testpassword localhost 0 testing123
Documenta la sortida i identifica els camps de la resposta RADIUS (Access-Accept o Access-Reject).

Gestió de Credencials Privilegiades (PAM)

Privileged Access Management

PAM (Privileged Access Management) és el conjunt de tecnologies i processos per controlar, monitoritzar i protegir els comptes privilegiats (administradors, comptes de servei, comptes de root).

Funcionalitats principals dels sistemes PAM:

  • Coffre de contrasenyes privilegiades: Emmagatzema contrasenyes d'administrador amb accés controlat i auditat.
  • Just-in-time access: Concedeix privilegis temporals per a tasques específiques, sense comptes d'administrador permanents.
  • Session recording: Grava totes les sessions privilegiades (vídeo + keystrokes) per auditoria forense.
  • Least privilege enforcement: Garanteix que cap compte tingui més privilegis dels necessaris.
  • Credential rotation: Rota automàticament les contrasenyes de comptes de servei.

Eines PAM comercials i de codi obert: - CyberArk: Líder del mercat empresarial - BeyondTrust: Solució completa PAM - HashiCorp Vault: Gestió de secrets + capacitats PAM - Teleport: Open source, accés SSH/Kubernetes/DB amb auditoria completa

# Exemple: Teleport per a accés privilegiat auditat
# El servidor Teleport actua com a proxy d'autenticació
docker run -d \
  --name teleport-NOMCOGNOM \
  -p 3022:3022 -p 3080:3080 \
  -v ./teleport-data:/var/lib/teleport \
  public.ecr.aws/gravitational/teleport:latest \
  teleport start --config=/etc/teleport.yaml

Principi de mínim privilegi en la pràctica

  • Crea comptes de servei amb els permisos mínims necessaris (no useu mai root o Administrator per a serveis).
  • Usa sudo amb regles específiques en comptes de donar accés complet de root.
  • Revisa periòdicament (trimestral) els comptes privilegiats i elimina els que ja no s'usen.
  • Per a entorns cloud (AWS, Azure, GCP), usa rols IAM amb política del mínim privilegi.

Cas Pràctic: Implementació PKI Corporativa

Escenari

L'empresa "Fabricats SA" vol implementar una PKI interna per: 1. Emetre certificats TLS per als seus serveis web interns 2. Usar certificats de client per a l'autenticació VPN dels empleats 3. Emetre certificats per a la WiFi WPA2-Enterprise amb EAP-TLS

Exercici

  1. Dissenya la jerarquia de la PKI (Root CA → Intermediate CAs) justificant l'estructura.
  2. Crea la Root CA amb OpenSSL seguint els passos indicats anteriorment.
  3. Crea una Intermediate CA per a servidors (vàlida 5 anys, signada per la Root CA).
  4. Emet un certificat de servidor per a intranet.fabricats.local (vàlid 1 any) amb els SANs adequats.
  5. Emmagatzema la Root CA de forma segura (descriu el procediment d'un sistema air-gapped).
  6. Explica com distribuiràs la Root CA als dispositius dels empleats perquè confïin en els certificats emesos.

Recursos

Eines

  • OpenSSL: Biblioteca criptogràfica per crear i gestionar certificats
  • easy-rsa: Scriptets per gestionar una PKI senzilla
  • CFSSL: PKI toolkit de Cloudflare
  • FreeRADIUS: Servidor RADIUS de codi obert
  • Teleport: PAM i accés privilegiat de codi obert

Documentació