Construction d’un accès sécurisé

Le problème que règle l’accès « zéro confiance »

Situation courante : l’accès signifie encore se connecter au VPN et être digne de confiance, même si le travail à distance, les sous-traitants et le SaaS ont rendu ce modèle non sécuritaire. Cause profonde : la confiance réseau implicite et un accès interne à plat donnent à une identité ou à un appareil compromis une portée latérale bien plus grande que nécessaire ; les produits ZTNA sans modèle de politique d’accès ne font que déplacer le problème.

Ce que vous possédez à notre départ

• Un modèle de politique d’accès exprimé en politique en tant que code (identité + posture de l’appareil + sensibilité de la ressource → autoriser/refuser), dans votre dépôt.
• Du Terraform/IaC pour les points d’application dans la portée (accès sensible à l’identité, segmentation, accès conditionnel, authentification service à service).
• Un modèle de menaces montrant les chemins de mouvement latéral avant et après, pour que la réduction du risque soit lisible et vérifiable.
• Des guides d’exploitation de déploiement par phases (pour basculer sans verrouiller vos propres employés à l’extérieur) et des procédures d’accès d’urgence (break-glass).
• Des ADR pour les décisions de frontières de confiance et d’application.

Pas un tableur de modèle de maturité. Un modèle d’application fonctionnel défini sous forme de code.

Notre façon de procéder

1. 01

   Découverte

   Nous lisons directement vos comptes, vos configurations et vos contraintes (accès en lecture seule à portée définie ou état exporté), nous cartographions l’état actuel réel et nous convenons d’une portée écrite et de critères de réussite avant d’écrire la moindre ligne de code.

2. 02

   Registres de décisions d’architecture (ADR)

   Nous consignons les décisions clés — ce que nous faisons, les options écartées et les raisons — sous forme d’ADR dans votre dépôt, afin que le raisonnement survive longtemps après notre départ et que vous puissiez le remettre en question avant que nous construisions quoi que ce soit.

3. 03

   Implémentation

   Nous bâtissons la solution sous forme de Terraform/IaC révisable, dans de petites pull requests testées et intégrées à votre CI, pour que vous la voyiez arriver progressivement et que rien ne débarque comme une boîte noire.

4. 04

   Transfert

   Nous guidons votre équipe en direct à travers le dépôt, le modèle de menaces et les guides d’exploitation, nous confirmons que vous pouvez l’appliquer, le détruire et l’étendre vous-mêmes, puis nous partons. Vous êtes propriétaires de tout : il n’y a pas de phase 5 où vous avez encore besoin de nous.

Forme du mandat

Une construction à portée fixe sur un ensemble défini d’utilisateurs, d’applications et de chemins d’accès — par phases, de sorte que chaque bascule soit réversible et observée. La portée est bornée par les chemins d’accès et les points d’application inclus dans la première phase, convenus d’avance.

Un exemple illustratif du format

# policy/access.rego — identity + device posture + sensitivity
package access

default allow := false

allow if {
  input.user.mfa_verified
  input.device.managed
  input.device.disk_encrypted
  resource_tier_permitted
}

resource_tier_permitted if {
  input.resource.tier != "restricted"
}

resource_tier_permitted if {
  input.resource.tier == "restricted"
  input.user.group in data.restricted_access_groups
  input.device.posture_checked_within_hours <= 24
}