Aller au contenu principal

JIT access

Just-in-Time access : un user demande un acces temporaire a une connexion (typiquement prod), un admin approuve, l'acces s'autodetruit a expiration.

Quand l'utiliser​

  • Un dev support a besoin de regarder la prod 30 minutes pour reproduire un bug. Pas la peine de lui donner un acces permanent.
  • Une investigation incident : acces grants temporaires plutot que credentials partages.
  • Conformite : prouver que les acces prod sont rares, traces, expirent.

Workflow rapide​

  1. User : Demandes d'acces -> Nouvelle demande. Choisir connexion, raison, duree (max policy).
  2. Admin recoit notification. Reviewer, approuver / rejeter.
  3. Approve -> Auralith cree une ProjectPermission temporaire avec expires_at.
  4. Le access_sweeper (cron) revoque automatiquement les permissions expirees.
  5. Toutes les actions du user durant l'acces sont taggees dans l'audit log avec le request_id.

Concepts cles​

  • AccessRequest : id, user_id, connection_id, reason, requested_until, status (pending / approved / rejected / expired).
  • access_sweeper : tache de fond qui scanne les permissions expirees et les revoque toutes les minutes.
  • Audit linkage : tout audit log durant la fenetre d'acces porte access_request_id -> tracabilite parfaite.

Pieges courants​

  • Duree max policy : si la policy plafonne a 4h, on ne peut pas demander plus. Demande rejetee automatiquement.
  • Revocation immediate : un admin peut revoquer une grant active a tout moment. La connexion DB se ferme au prochain check (timeout < 60s).
  • Pas une grant SQL native : Auralith gate au niveau applicatif, pas via GRANT SQL. Si le user a un acces direct au host DB, il contourne. Recommande : exposer la DB uniquement via Auralith.

API​

curl -X POST https://app.auralith.io/api/v1/projects/{pid}/access-requests \
  -d '{"connection_id":"...","reason":"investigate ticket #1234","duration_minutes":60}'

Voir aussi​