Token storage & encryption policy
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.
Application-Level Encryption with AES-256
All Microsoft Entra & Atlassian access tokens are encrypted at the application level using the AES-256 encryption standard. This ensures that even if data were intercepted at rest or in transit, it would remain unreadable without the appropriate decryption key.
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.