This article details our internal policy how we handle and store sensitive credentials like Microsoft Entra access tokens within our AWS infrastructure. By following these stringent practices, we ensure that Microsoft Entra access tokens—and all sensitive credentials—remain secure at every stage of their lifecycle.
Secure Token Service - STS
Tokens used to access customer infrastructure (e.g. Entra ID access tokens) are the most critical assets and are managed by a dedicated service to mitigate prevalent attack vectors.
The STS operates within an isolated environment with distinct secrets and scoped permissions.
Support personnel and our other services are explicitly restricted from accessing any customer tokens directly and have to use the STS.
Technically, the tokens are stored in a dedicated database with restricted, scope-limited permissions. Additionally, access and refresh tokens are encrypted at the application layer using AES-256. STS is accessible only by authorized consumers within the private network.
Key Management via AWS Secrets Manager
The encryption secret used for AES-256 encryption is securely stored in AWS Secrets Manager which encrypts secrets at rest using AWS Key Management Service (KMS) and provides fine-grained access controls via IAM. This offers robust, least-access based security and centralized audit logging.
Access Control to the Encryption Key
Access to the encryption key is highly restricted.
Only our production environment is permitted to retrieve the encryption secret to decrypt tokens as needed during runtime. This is enforced through IAM roles and fine-grained permissions to ensure secrets are never exposed in development, staging, or non-production environments.
-
In addition, only our technical leadership has (audited) access to manage or view this secret in exceptional cases like rotating the secret.
-
Neither general employees nor developers have access to to the secret.
-
Access is tightly controlled using AWS IAM policies and multi-factor authentication (MFA).
Industry-Standard Access Controls in Production
In addition to securing direct access to the key, we also implement the following best practices for protecting our production infrastructure, so that even indirect access to the secret is not possible.
-
Role-Based Access Control (RBAC): Access is granted based on job roles, ensuring users only have the permissions they need.
-
Multi-Factor Authentication (MFA): All administrative and infrastructure access requires MFA to prevent unauthorized logins.
-
Least Privilege Principle: Every service and user operates with the minimum level of access required.
-
Network Segmentation: Sensitive services run in isolated private subnets with strict ingress and egress rules.
-
Audit Logging and Monitoring: All access to secrets, production servers, and infrastructure components is logged and monitored continuously for suspicious activity.
-
Immutable Infrastructure: Deployments use version-controlled, infrastructure-as-code definitions to ensure traceability and prevent configuration drift.
Secure Development Practices
We enforce secure coding guidelines that emphasize the correct handling of sensitive data such as tokens and access credentials—particularly in logging and error reporting. All code undergoes peer code reviews with a focus on identifying potential security risks. Additionally, we conduct thorough vetting of software dependencies for known vulnerabilities and maintain a proactive schedule of timely updates and patches to mitigate emerging threats, using a combination of tools like Vanta, Microsoft Defender, Github Advanced Security and more.