Specific inquiry
I am responsible for the technical side of information security at my company. The IT department has decided to develop information systems based on a microservice architecture.
I have looked for related material, but most of it is conceptual. I am requesting help on the specific items I should present to the IT development department as security requirements.
Security requirements for a microservice architecture
While providing secure-development consulting on information system development based on a microservice architecture, primarily for financial companies, we organized 48 standard security requirements in six domains.
A microservice architecture implements many microservices as Docker containers that each provide a separate service port, so nearly every part of the information security architecture—including authentication, access rights, logging, encryption, and protection of personal (credit) information—must be reexamined from a different perspective. Considering that some foreign banks have cases composed of about 1,500 microservices, the complexity and diversity make management itself difficult unless it is automated with a dedicated tool such as Kubernetes orchestration. The architecture also centralizes authentication, logging, encryption, and similar controls through an API gateway and links a vulnerability-analysis plugin to CI/CD tools, so it is structured such that a Shift Left strategy has to be used. We have developed a practical guide that specifies these security requirements and are using it, and we continuously update all of the documents.
| Domain | Number of requirements |
|---|---|
| 1. Requirements related to integrated management | 13 |
| 2. Requirements related to authentication | 14 |
| 3. Requirements related to API keys and signed requests | 7 |
| 4. Requirements related to deployment | 4 |
| 5. Restrictions on data and messaging privileges | 6 |
| 6. Requirements related to monitoring and logging | 4 |
| Total | 48 |
1. Requirements related to integrated management
1.1 Restrict use to approved application containers
| In a microservice architecture, the number and complexity of services increase, so from an attacker’s perspective the attackable scope of the overall system can expand. Therefore, as a way to minimize the attack surface, use must be restricted to approved application containers. |
1.2 Keep the container environment current and secure
| System administrators must ensure that the container runtime environment is continuously kept up to date. In accordance with organizational policy, the container environment must be maintained in a current and secure state. |
1.3 Container security configuration
| Apply security settings to containers. For example, apply security settings according to authoritative guides on container security, such as the non-root (or rootless) setting supported in Docker Container 19.03 and later. |
1.4 Apply IP filtering to control access by a specific IP address or IP address range
| IP filtering must be applied to control the connectivity of microservices running on a host. IP filtering can allow or restrict access from a specific IP address or IP address range, which prevents indiscriminate access and helps keep microservices secure. |
1.5 Compose services through an API gateway
| Communication between microservices (east-west communication) must take place through an API gateway, and authentication, authorization, logging, and alerting functions must be configured there. When communication passes through the gateway, all traffic is centralized, so authentication management, authorization management, logging management, alert management, and load balancing can be implemented. |
1.6 Minimize container service ports
| A container that hosts a microservice must be limited to a single port or the minimum service ports required to provide the service, and every other service port must be explicitly blocked to reduce potential security risks. |
1.7 Provide tools to monitor and visualize inter-service communication
| Microservices communicate with one another in many ways, so tools must be operated to monitor and visualize the patterns and complexity of inter-service communication. These tools manage microservice complexity, check service health, and can quickly detect potential problems or factors that reduce efficiency. |
1.8 Deploy communication-monitoring tools and configure thresholds
| To monitor communications in a microservice environment and detect anomalies quickly, a baseline for normal communication volume must be set, and monitoring-tool thresholds must be configured so that an alert is raised when an event such as a traffic spike or an abnormal communication flow is detected. |
1.9 Logically separate the networks of the development, test, and production environments
| The development, test, and production environments must be separated into logically distinct networks. Because the purposes of the development, test, and production environments differ, running each on a separate network prevents potential errors or security threats from spreading to another environment. |
1.10 Publish the API catalog and its characteristics
| Publish the API catalog and its characteristics so that developers using the software can clearly understand the functions, URIs, and other specific requirements for using the service. Developers who use those APIs can then interact with the service in a more effective and secure way. In particular, recognizing important information such as functions, URIs, and other requirements reduces incorrect use and errors. |
1.11 Build a system for continuous monitoring of resource usage and performance
| Resource usage and performance of microservices must be monitored continuously so that excessive requests for resources or unexpected usage spikes can be identified quickly. When resource usage spikes, capacity management can allocate additional resources or optimize existing resource use to maintain service stability. |
1.12 Protect microservices with a defense-in-depth strategy
| Microservices must be protected with a defense-in-depth strategy, which must include filtering of communication flows, authentication and authorization for access to microservices, and encryption. In other words, to protect microservices, communication flows are filtered to block unwanted access, users or systems are authenticated and granted appropriate privileges when they access a microservice, and encryption is used to assure the confidentiality and integrity of data. |
1.13 Do not retain sensitive information in the API gateway
| Except while functions that inspect or analyze traffic are operating, an API gateway must not retain sensitive information such as personal (credit) information in memory for a long time. This is because there is a risk of leakage of sensitive information such as personal (credit) information, or of violating related laws or regulations. |
2. Requirements related to authentication
2.1 Define authentication standards early in the software development lifecycle
| The authentication model for microservices must be defined early in the software development lifecycle in order to reduce the risk of security violations and establish an effective authentication method. Even when federated identity—a method of sharing a user’s identity and privileges across multiple domains and applications—simplifies access control among various systems and applications, authentication-related security standards must be followed and the service must be assured to operate in a trustworthy manner. |
2.2 Use an open standard protocol such as JWT for authentication technology
| Authentication technology must use well-known, secure open standard protocols such as JWT and OAuth 2.0. In an MSA, unlike a typical access-token approach, a JWT (JSON Web Token) that carries the user’s authentication information is used as the standard. In an API gateway environment, a user or system attaches a JWT and requests an operation from a service through the API gateway, and the service processes the request based on the user authentication information attached by the API gateway. |
2.3 Use a secure cryptographic algorithm for token-based authentication
| A token-based authentication mechanism must use a secure cryptographic algorithm in accordance with cryptographic guidance. Assuring the strength of the cryptographic algorithms used to generate tokens, together with key management and other security measures, strengthens the security of token-based authentication. |
2.4 Minimize concurrent authentication and set a maximum limit
| To strengthen the usability and security of the service, a user or process may be allowed to use multiple authentications at the same time, but a strict maximum limit on concurrent authentication must be set to prevent potential risks such as a large volume of fraudulent authentication requests. |
2.5 Set a TTL (time to live) on authentication tokens to prevent replay attacks
| Authentication tokens must have a TTL set in order to prevent replay attacks. Setting a TTL (time to live) on a token makes it possible to identify expired tokens whose TTL has elapsed and to prevent a replay attack that reuses a previously used valid session. |
2.6 Update the TTL to a new expiration time on every token revalidation
| The TTL (time to live) of an authentication token must be updated to a new expiration time whenever the token is revalidated, in order to strengthen token security. If a user or system continues to use the service in an active state, the token is extended with a new TTL during revalidation. If the user or system stops using the service, the token expires according to the initially set TTL. This allows the user to continue activity without service interruption while active, while tokens that remain inactive for a long time expire automatically and security is maintained. |
2.7 Block expired tokens and return an error code
| A token whose period has expired must be blocked when authentication is requested, and an appropriate HTTP error code (for example, 401) must be returned to the user. Allowing an expired token can cause a security problem, so an authentication request that uses an expired token must be blocked. If the system detects an authentication request that uses an expired token, it must return HTTP error code 401 (“Unauthorized”) to the user. |
2.8 Delete expired tokens from memory
| Expired tokens must be deleted from memory on a regular basis. Retaining expired tokens in memory not only consumes resources unnecessarily but can also be abused as a potential security weakness, so expired tokens must be removed from memory regularly in order to maintain the efficiency and safety of the system. |
2.9 Prevent reuse of delegated requests
| Measures must be in place so that a request that has received delegated authority from another user or service, as in OAuth authentication, cannot be replayed maliciously. A replay attack is an attempt by a malicious user to capture a previous valid communication and send it to the server again in order to access information or a service, and the control prevents a delegated request from being reused. |
2.10 Follow PKI best practices when exchanging JWT certificates
| When JWT is used for authentication, PKI best practices must be followed for certificate exchange. A JSON Web Token (JWT) contains claim-based information, and following PKI best practices when certificates are exchanged in authentication that uses it provides assurance of safety. |
2.11 Encrypt authentication tokens
| Authentication tokens must be encrypted in order to minimize risk even if a token is leaked. An authentication token contains authentication and authorization information, so exposure to a malicious user can create a security threat. Encrypting the token so that its contents are not easily deciphered even if it is stolen therefore minimizes the risk. |
2.12 Authenticate every API endpoint at the gateway
| Every API endpoint must be authenticated by the gateway. Because all communication with an API endpoint takes place through the gateway, authenticating at the gateway prevents invalid or malicious requests from entering the system and strengthens the security of the entire system through a centralized authentication mechanism. |
2.13 Limit authentication failures and configure alerts in the gateway authentication function
| The gateway must limit the number of authentication failures and implement a mechanism that reports repeated authentication failures. Multiple authentication failures can indicate that a malicious user or system is attempting a brute-force attack. To respond to this threat effectively, the gateway must detect consecutive authentication failures, limit that count, and send an alert to administrators or responsible staff so they can respond immediately. |
2.14 Follow the password policy when a password must be used as an exception
| If using a password is exceptionally unavoidable, allow it according to the organization’s internal policies and procedures, and apply password strength, handling from creation through disposal, and periodic review to prevent misuse. |
3. API Key and signed-request requirements
3.1 Implement an integrity mechanism for transmitted data
| A service must implement a data-integrity mechanism to confirm that transmitted data was not changed in transit. The service must verify that data was not tampered with during transmission by using a mechanism such as a checksum or hash verification. |
3.2 Apply authentication and encryption to inter-service communication
| Communication between services (a microservice, or a function-call structure between applications) must take place over a secure channel so that an attacker cannot intercept an API call on the network and attack the service, and appropriate authentication and encryption mechanisms must be applied. |
3.3 Compose an API key from a unique service ID and user ID
| Each individual service must have a unique API key in order to call another service, and that key must be composed at least of a unique service ID and a user ID. The uniqueness of an API key is an important factor in strengthening the security of communication between services, so using a unique API key for each service allows the authentication and authorization of each service to be managed accurately. When a key is composed of a service ID and a user ID, it is possible to identify precisely which service a request comes from and which user executes it. |
3.4 Apply encryption (TLS) on the path where API keys are sent and received
| API key communication must use encryption in transit (TLS). An API key is important information for authentication and authorization between services, so the key must be protected from external malicious attackers while it is sent and received. Encryption in transit (TLS) provides safety from external intruders when data is transmitted over the network and assures the confidentiality and integrity of the data. |
3.5 Apply a cryptographic signature to every API request
| Every API request must be cryptographically signed, and the signature must include at least the request parameter data, the service ID, the API key, and the original timestamp. Cryptographically signing an API request makes it possible to verify the integrity and origin of that request, and including several pieces of information in the signature makes it possible to check whether the request was changed or tampered with in transit. In particular, because important information such as the request parameter data, the service ID, and the API key must be included in the signature, integrity verification of the request is much stronger. The original timestamp helps confirm the request TTL (time to live) and prevent replay attacks. |
3.6 Generate functions used in service development with an SDK
| Functions used for service development must be generated with an approved SDK. Using an approved SDK requires developers to write code with tools that have been judged verified and safe, which assures the stability and security of the software being developed. |
3.7 Comply with security standards when developing microservices
| When developing microservices, related security-standard guidelines and guides must be followed, including OWASP, SANS, secure coding guides, and the vulnerability assessment criteria for electronic financial infrastructure. Compliance can improve the security and stability of microservices. Most organizations build a CI/CD system with Jenkins or similar tools and operate every stage of a microservice—Plan-Code-Build-Test-Release-Deploy-Operate—through automation, and they apply a Shift Left strategy by integrating security-vulnerability tools as Jenkins plugins. |
4. Requirements related to deployment
4.1 Apply deployment-management policy automatically through orchestration
| Policy for the deployment and management of microservices or containerized applications must be applied in an automated way, as part of the orchestration procedure, in order to enforce segmentation. Applying policy in an automated way through the orchestration process, so that the orchestration tool applies policy automatically and guarantees segmentation (or separation) between systems, maintains the consistency of the infrastructure, minimizes errors that can occur in manual configuration, and makes it possible to comply thoroughly with security requirements. |
4.2 Apply the latest security updates to every microservice component
| Every component required for a microservice to operate smoothly must have the latest security updates and patches applied. Performing this patching periodically and systematically maintains the security and stability of the microservice. |
4.3 Automate deployment and updates with an orchestration tool
| Deployment and updates must be automated by using an orchestration service. An orchestration service is a tool that helps with the automatic deployment and management of multiple services or applications, so it provides benefits such as consistent deployment, faster market response, and fewer errors. Automated deployment reduces human error that can occur in manual work, shortens deployment time, and can improve system stability. |
4.4 Encrypt all network traffic, including authentication credentials, with TLS in transit
| All network traffic between endpoints in a microservice architecture, including authentication credentials, must use TLS to secure data sent and received. Traffic that contains sensitive information such as authentication credentials is especially important, so using TLS to protect it is essential. |
5. Restrictions on data and messaging privileges
5.1 Establish and apply a policy that minimizes unnecessary API calls
| API calls must be limited to those required for the user or system to perform its function, so that unnecessary API calls are minimized. If a user or system can access more APIs than necessary, that can become a potential security threat. Restricting calls to only the APIs required to perform a specific function prevents API abuse and can strengthen security. |
5.2 Establish and apply a policy that minimizes unnecessary data access
| Under the principle of least privilege, the data that can be used must be limited to the minimum data required for the service to perform its function. Granting a service more data-access privileges than it needs can become a potential security risk. Providing only the data that is strictly required to perform a specific service function minimizes the risk of data leakage or unauthorized access and can improve the security of the service. |
5.3 Apply access control so database credentials can reach only the minimum data
| A database credential must be able to access only the minimum data required to perform the function for which that credential was issued. If a credential has excessive access privileges, exposure of that credential can put a large amount of information in the database at risk. The credential must therefore be restricted so that it can access only data related to the specific function it is meant to perform. In this way, the amount of data exposed is minimized even if the credential is disclosed without authorization. |
5.4 Apply access control so database credentials can use only the minimum required functions
| To restrict access to database functions and operations, a database credential must be able to access only the functions and operations required to perform the function for which that credential was issued. The privileges granted to each credential must be limited to the purpose of that credential. For example, a credential for a function that only needs to read certain data must not have permission to modify or delete data. These restrictions minimize the risk from incorrect use or unauthorized use. |
5.5 Apply access control so messaging channels are limited to the minimum
| To restrict access to messaging channels, a service must be implemented so that it can access only the messaging channels required to perform its function. If a service can access messaging channels unrelated to its function, that can become a security threat such as sending an incorrect message or unauthorized access to sensitive information. A service must therefore be restricted so that it can access only messaging channels related to the purpose of that service. |
5.6 Segment messaging-channel privileges and apply the minimum
| To segment access privileges for messaging channels, access to an assigned messaging channel must be limited to the functions that are needed, such as read-only and write. For example, if a service only needs to read messages, it must not be granted write permission on that channel. Segmenting access privileges to match each function reduces the risk from incorrect operations or unauthorized operations. |
5.6 Apply protective measures to the storage and transmission of messaging credentials
| Appropriate protective measures must be applied to messaging credentials whether they are stored or in transit. Messaging credentials at rest or in transit can cause serious harm if exposed to an attacker, so they must be properly protected by methods such as encryption. |
6. Requirements related to monitoring and logging
6.1 Generate logs for every microservice
| To assure the transparency and traceability of every activity related to microservices, each microservice and the microservice gateway must generate appropriate logs in accordance with the organization’s security policy. Logs record activity in the system and provide important information when security issues or system errors are investigated, so logs are generated in order to maintain the stability and security of the system. |
6.2 Store every API request in a centralized logging and monitoring system
| Every API request must be recorded in a centralized logging and monitoring system. This makes it possible to detect and respond quickly to events such as security violations, system errors, and unauthorized access. |
6.3 Log microservice performance and throughput metrics and set normal baselines
| For performance monitoring and optimization of microservices, performance and throughput metrics must be logged and a baseline set of normal metrics must be established. Performance and throughput metrics provide important information for evaluating the operating state and efficiency of a service. Establishing a baseline set of normal metrics makes it easier to detect and respond to variation or abnormal behavior in the system. For example, if a metric changes sharply, that can indicate a problem in the system, so immediate action is required. |
6.4 Set metrics for abnormal activity and configure alarm thresholds
| The logging and monitoring system must have thresholds that raise alerts for abnormal metrics so that abnormal system activity can be detected and handled quickly. For example, if a service’s throughput drops sharply below its usual level, that can indicate a problem with the service. In that case, when the threshold is reached, the logging and monitoring system can immediately notify an administrator or responsible person and prompt an investigation. |