Security (AuthN, AuthZ, Encryption)
Operating a Production System
Security is not a feature; it's a fundamental requirement of any production system. In a system design interview, demonstrating that you are thinking about security from the beginning is a sign of a mature and responsible engineer.
This chapter covers three core pillars of security: Authentication (AuthN), Authorization (AuthZ), and Encryption.
AuthN: Who Are You?
Authentication is the process of verifying the identity of a user or service. It answers the question, "Who are you?"
Common Authentication Mechanisms:
- Username/Password: The most basic form, but it has security risks (e.g., weak passwords, password reuse).
- Multi-Factor Authentication (MFA): Provides a second layer of security by requiring two or more verification methods (e.g., a password and a one-time code from a mobile app).
- OAuth 2.0: An open standard for access delegation. It's commonly used to allow users to sign in to a third-party application using their existing account from a trusted provider like Google, Facebook, or GitHub. The third-party application receives an access token, not the user's actual credentials.
- JSON Web Tokens (JWT): A compact and self-contained way for securely transmitting information between parties as a JSON object. A JWT is "signed" by the authentication server using a secret key. When a client sends a request to a resource server, it includes the JWT in the
Authorization
header. The resource server can then verify the signature of the JWT to ensure it's authentic, without having to call back to the authentication server. This makes JWTs a very scalable and popular choice for securing APIs in a microservices architecture.
AuthZ: What Are You Allowed to Do?
Once a user has been authenticated, the next step is authorization. Authorization is the process of determining whether an authenticated user has permission to perform a specific action or access a specific resource. It answers the question, "What are you allowed to do?"
Common Authorization Models:
- Role-Based Access Control (RBAC): This is the most common model. Users are assigned roles (e.g.,
admin
,editor
,viewer
), and permissions are granted to those roles. A user can perform an action if they have a role with the required permission. - Attribute-Based Access Control (ABAC): A more fine-grained model where access rights are granted based on attributes of the user (e.g., their department), the resource being accessed (e.g., its sensitivity level), and the current environment (e.g., the time of day).
Where to Enforce Authorization: In a microservices architecture, authorization can be enforced at multiple levels:
- At the API Gateway: The gateway can perform coarse-grained authorization checks. For example, it can check if the user has the
admin
role required to access an admin-only endpoint. - Within the Service: Each microservice should be responsible for its own fine-grained authorization checks. For example, an Order Service should check if the authenticated user is the owner of the order they are trying to access. A service should never blindly trust a request, even if it comes from the API Gateway.
Encryption: Protecting Data
Encryption is the process of converting data into a code to prevent unauthorized access. There are two main contexts for encryption in system design:
1. Encryption in Transit
This protects data as it travels over a network. The standard for this is TLS (Transport Layer Security), which is the protocol that powers HTTPS.
- How it works: TLS uses a combination of symmetric and asymmetric encryption to establish a secure, encrypted channel between a client and a server. This prevents eavesdropping and man-in-the-middle attacks.
- Rule of Thumb: All communication over a public network (like the internet) must be encrypted with TLS. Communication within your own private network (e.g., between your microservices) should also be encrypted as a best practice (this is known as a "zero-trust" network policy).
2. Encryption at Rest
This protects data when it is stored on a disk or in a database.
- How it works: Data is encrypted before it's written to the storage medium and decrypted when it's read. This ensures that even if an attacker gains physical access to your servers or database backups, they cannot read the data without the encryption keys.
- Key Management: The most challenging part of encryption at rest is key management. You need a secure way to store and manage your encryption keys. This is often handled by a dedicated Key Management Service (KMS), such as AWS KMS or HashiCorp Vault.
- Rule of Thumb: All sensitive user data (like personally identifiable information (PII), passwords, and financial data) must be encrypted at rest. Most managed database and storage services in the cloud provide this as a standard, configurable option.
In a system design interview, you should explicitly mention these security considerations.
- "For authentication, I would use an OAuth 2.0 provider and issue JWTs to clients."
- "Authorization will be handled at two levels: role-based checks at the API Gateway and resource-based checks within each service."
- "All external traffic will be encrypted in transit using HTTPS/TLS. All sensitive data in the database will be encrypted at rest, with keys managed by a KMS."
This demonstrates that you are building a system that is not just scalable and reliable, but also secure.