Solution
Identity, directory and access
Many incidents run on a valid account whose password was stolen, or on an account holding too many rights. I design the directory, Active Directory or Entra ID for instance, connect the compatible applications, carry every right through a group that names a role, put technical keys and passwords in a vault, and verify that a departure closes every access.
The gains from a directory kept in order
A departure follows a verifiable path
Federated applications follow the central disablement, and the exceptions sit in an assigned list. The final reconciliation proves the closure; one click doesn’t.
The access question has an answer
A client, an auditor or an insurer receives a dated record with scope, exceptions and the latest review. Every right carries the name of the group that explains it.
Technical keys stop circulating
Service passwords, API keys and certificates get an owner and a rotation date in a vault. An exposed secret is replaced by procedure, not by investigation.
Fewer passwords, not more
One directory cuts the number of sign-ins without weakening the controls. You still require a fresh authentication according to the device, the application and the risk.
In practice
- Directory design or takeover: Active Directory, Entra ID or Google Workspace as the source of record, with compatible applications federated through SAML or OpenID Connect
- Group architecture: groups that describe people, groups that describe rights, and the first feeding the second
- Multi-factor authentication applied first to privileged accounts and remote access, with a recovery method matched to the risk
- A joiner, mover and leaver procedure, with the list of rights granted, retained and removed
- Privileged accounts separated from everyday accounts, and a sealed break-glass account for the day the directory itself is down
- A secrets manager for technical passwords, API keys and certificates, with an owner, a rotation date and scanning for secrets left in code
- An access review scheduled by risk, with an owner, an exception list and a transferable procedure
Systems involved
- Active Directory, Microsoft Entra ID, Google Workspace
- SAML or OpenID Connect applications, code repositories and CI tooling
- Secrets managers and team password vaults
- FIDO2 keys and authenticator applications
- Terraform to describe groups and roles in the cloud
Service lineServers and hosting →
The access to govern
The same work, against each sector’s own constraints. Every card opens the full sector.
Banking and insurance
Access rights carried by roles
Every access to client or market data corresponds to a named role, with its justification and its latest review. The auditor reads the matrix; nobody rebuilds it for them.
Energy and utilities
Access to operational data assigned by role
Exchanges with the operational systems, the market portals and the partners run through inventoried technical accounts, each with an owner and a rotation date. A departure closes the access the same day.
Healthcare and life sciences
Role-based access to the record and the laboratory
Clinicians, researchers and administration receive their rights through groups that describe their role, with the review professional secrecy requires and a verified closure at every departure.
Logistics and supply chain
Partner and site access under one directory
Carriers, sites and temporary staff receive accounts tied to a person and a role, with an end of assignment that closes the access on the planned day, portal included.
Retail and e-commerce
One account per person in every shop
Sales staff, managers and seasonal workers receive their rights through groups that follow the role and the shop. An end of contract closes the till, the tenant and the supplier portal the same day.
How it runs
Inventory
Accounts, applications, shared access, service accounts and secrets are reconciled against the lists you have. Each gap gets a priority and an owner.
Architecture
I draw the groups and roles, then connect the applications to the directory one by one, keeping the old sign-in open until the new one is validated.
Hardening
Second factor and device conditions applied by risk, privileged accounts separated, secrets migrated into the vault and the emergency account tested.
Handover
Your team receives the joiner and leaver procedures, the review method, the map of connected applications and the secret-rotation procedure.
To go deeper
Cloud access on Google Cloud, Azure, AWS and Infomaniak
The same four decisions on four platforms, and an honest account of the gap: Infomaniak gives you Swiss residency and OpenStack portability, and gives you no inherited permissions, no device-aware sign-in rules and no expiring administrator role.
Five threats to a Swiss organisation, and the control that blocks each one
Documented Swiss incidents point back to the same controls: exposed services, identity, payments, suppliers and recovery. The order still needs to fit the organisation's risk.
Dependencies and next steps
Test the fit: Identity, directory and access
Describe the context, constraints and decision you need to make. The first conversation qualifies scope, boundaries and the next useful step.
Describe the situation