Service Account Standardisation and Rotation RFC
This blueprint is designed to articulate a comprehensive approach to standardising and establishing a service account management framework. It delineates the necessary tasks to improve identified issues related to service accounts on AWS and GCP cloud providers.
A Service Account is a dedicated account for applications or services, enabling interactions and access to resources within a system. Unlike user accounts, Service Accounts are tailored for automated tasks and follow the principle of least privilege. They play a key role in ensuring secure communication and controlled access in various computing environments.
The blueprint specifically addresses prevalent problems, lack of standardisation, and challenges in the context of service accounts on these cloud platforms.
- Absence of Naming Conventions: Service accounts lack a consistent and standardised naming convention, leading to confusion and potential security risks.
- Insufficient Rotation Practices: The blueprint acknowledges the prevalent issue of inadequate rotation practices for service account's keys, as evidenced by the Security Dashboard, posing a significant security threat.
- Lack of Standardised Procedures: The absence of standardised procedures for managing service accounts contributes to inconsistencies and hampers effective governance.
- Missing Owner Identification: Service accounts lack clear owner identification, resulting in accountability challenges and potential security vulnerabilities.
- Not following the principle of least privilege and auditing: Service accounts are overprivileged in most cases, posing a risk vector if compromised. Ebury has introduced a product initiative to define a comprehensive RBAC system within GCP and AWS, ensuring users and service accounts are granted permissions strictly based on their roles and responsibilities following the Principle of Least Privilege (PoLP).
ISO 27001 is one of Ebury's goals and the process to establish a service account management framework which includes the key management policy that complies with the ISO standard is essential.
Scope
The scope includes proposing solutions to enhance security measures, introduce standardisation, and establish a robust service account management framework,
- on all service accounts on AWS and GCP,
- affecting naming conventions for service accounts,
- credential rotation policies,
- monitoring practices for the efficacy and compliance of service accounts
Problem Description
A recent review of AWS service accounts, conducted in our security dashboard, has highlighted several concerns related to AWS where the monitoring is implemented:
From a total of 160 service accounts, 148 have not had their credentials rotated in the last 90 days, including both production and non-production accounts:
A lack of standardised naming convention especially for AWS and GCP which would lead to not identifying the purpose of the account which can lead to confusion, as well as operational inefficiencies and difficulty in auditing and compliance. Lastly, this poses a security risk as there may be circumstances of unauthorised service accounts that are unmanaged. The root cause of this is a lack of ownership and detailed description/purpose of the service account:
Similarly, the same issue has been identified in GCP, where the “data-ci” project indicates that, out of a total of 64 service accounts with 75 active keys, 74 have not been rotated in 90 days.
Background
Service accounts play a crucial role in managing and operating cloud resources. They provide automated processes and services with the necessary permissions to perform their tasks within cloud environments. Proper management of these accounts is critical to maintain security and comply with best practices (i.e. IAM).
The findings from the security dashboard suggest that there is a clear need for improved governance around service accounts to improve the confidentiality, integrity and availability of our cloud infrastructures.
Solution
Name Standardisation
Having a consistent naming convention makes it easier to identify service accounts and their associated permissions. This helps reduce the risk of granting too many privileges or granting them to the wrong people. It also makes it easier for administrators to audit access rights and verify that only authorised users can access sensitive data.
A good naming convention should include information about the purpose of the account, such as its role in the organisation, its account, the project or the main purpose in lowercase.
| Prefix | Environment | Most privileged permission | Project |
|---|---|---|---|
| sa- | prod/dev/stg- | privileged/read/write- | projectname |
Examples:
- sa-prod-write-bos
- sa-dev-read-bos
Accountability
For accountability for service accounts, it is crucial to establish robust governance policies and the principle of least privilege, mandating that access is limited to the minimum necessary to perform required tasks. Additionally, conducting frequent audits, taking steps to prevent denial of responsibility, and continuously monitoring usage to identify irregular behaviours are essential practices. Effective accountability also entails keeping precise records for all service accounts, carefully overseeing who has the authorization to access them, and comprehensively understanding the dependencies of various services on each account.
- Accountability for Google Cloud Platform (GCP) service accounts is determined by the permissions allocated to these accounts through their roles, with accounts assigned the "owner" role being subject to management and rotation responsibilities.
- In Amazon Web Services (AWS), the ownership of service accounts is established through tagging the IAM resources, a methodology laid out in the next section on tagging strategy. These tags are crucial for tracking which individuals or teams are responsible for the service accounts, thereby facilitating better oversight and governance.
Tagging strategy
Using tags in AWS Identity and Access Management (IAM) is a practical way to identify service accounts, their owner or responsible parties, and the associated projects but on GCP service accounts can’t be tagged as an IAM resource.
Tags in AWS are key-value pairs that you can assign to AWS resources, including IAM users. Below is a step-by-step solution to implement this in AWS:
Tag Key: Type
- Value: ServiceAccount / User
- Description: This tag signifies whether an IAM user is associated with a specific individual or is part of an automated procedure. The IAM user in question serves the role of a Service Account.
Tag Key: Owner
- Value: Ebury team or group email address
- Description: This serves the purpose of identifying and associating an owner or responsible party with a specific AWS resource. In the context of resource tagging, the "Owner" tag contains information about the team, or department accountable for the management of the service account. This tag should be in place if the IAM resource type is a service account
Tag Key: Project
- Value:
- Description: The purpose of the tag with a value in a comma-separated list is to categorise and associate an AWS resource with multiple projects. This approach allows for more granular and flexible resource classification, as a resource can be linked to several distinct projects simultaneously.
Periodical cleanup of unused service account keys
Unused service accounts can become potential security risks, serving as entry points for unauthorised access. Cleaning up ensures a more secure environment, a part of that compliance standards often require regular audits and removal of unused accounts. A cleanup ensures adherence to these standards.
The process defined in this blueprint aims to review unused keys every 90 days:
- Identify Unused Accounts: Utilise GCP and AWS monitoring tools to identify service accounts with no recent activity or associated resources. Security Engineering can provide the existing metrics on the security dashboard to help identify service accounts and the teams can track if a service account is still in use or not.
- Service account owners receive a notification to review the service account every 90 days.
- Review Permissions: Verify that no critical permissions are associated with the identified unused service accounts and their keys before deletion.
- Delete Unused Service Accounts and their access keys: Using Terraform if it is possible or manually accessing the console
- Logging and Documentation: Maintain logs of the cleanup process and update documentation to reflect the changes.
Key Rotation
A process has been established where service account key rotation is managed by the designated owners and measured by Security Engineering in the Security Dashboard, the following steps are implemented:
Automated Notification System: An automated Security Engineering service has been implemented that monitors the age of service account keys and automatically sends out email notifications to the designated service account owners every 90 days.The notification includes a summary of the service account key status and detailed instructions for the review and rotation process. The email may also contain a direct link to the management console or portal where the service account keys can be managed.
Owner Action: Owners of the service account are expected to follow the prompted review upon receiving the notification. Their assessment should determine the necessity for key rotation or account cleanup, followed by the execution of the appropriate measures is imperative to document any changes made. Additionally, owner responsibilities may include adjustments on external services, such as Hashicorp Vault, where service account credentials are managed and stored.
Monitoring and Measurement: The Security Engineering team has monitored all the metrics on the Security Dashboard that integrates data from the notification system. The dashboard displays metrics such as key ages and compliance status. Owners can request access to this dashboard through the Security Engineering ticketing queue.
Enforcement Policy: The appropriate encryption policy and underlying standard are in place that specifies how often service account keys should be rotated. Under Section 7.2 of the standard, it mentions that automatic key rotation at a defined period, such as every 90 days, increases security with minimal administrative complexity. Policy non-compliance may lead to Ebury losing its ISO27001 certification which is used to attract clients.
Alternatives
The alternative approach is characterised by an absence of standardised processes, requiring individuals to manually identify code owners. Additionally, this method requires a periodic manual review of service accounts. It also needs a manual notification system, leading to a more time-consuming and potentially error-prone workflow, as updates and reviews must be tracked and conducted without the assistance of automation.
Caveats
- Each service account ought to have distinctly identified owners. It is advisable to utilise Infrastructure as Code scripts for the tagging procedure, which will facilitate the identification of service account owners on AWS. Using Policy-based control for cloud-native environments to enforce the use of tagging of specific resources (OPA)
- Moreover, to achieve standardisation, a renaming process for service accounts should be established, adhering to the naming conventions.
- Before implementing the notification system, a thorough review of service account IAM owners on GCP is necessary.
Operation
The responsibilities of identifying service account ownership sit with the technology teams as part of the existing responsibilities around service account management.
Monitoring KPIs and metrics around the Service Account rotation is performed by the Information Security team to guarantee their alignment with the Ebury security policies.
Security Impact
The service account standardisation and rotation on the cloud environments offer several security improvements:
- Enhanced Security: Rotating service account credentials helps mitigate the risk of credentials being compromised, as it reduces the window of opportunity for unauthorised access. Regular rotation of passwords and keys makes it more difficult for malicious actors to gain persistent access to your systems.
- Accountability: Identifying clear owners for each service account ensures that there's a directly responsible individual or team for managing and monitoring the account adding nonrepudation of actions. This accountability leads to better security practices and quicker response to any irregularities.
- Compliance: Regular rotation and clear ownership are often requirements for regulatory compliance in many industries.
- Operational Consistency: Standardisation of naming conventions simplifies the management of service accounts.
- Streamlined Auditing: Rotation and naming conventions enable better tracking and reporting on service account usage. When each account has a standardised identifier and a known owner, it simplifies the auditing process and contributes to transparent operational oversight.
Performance Impact
The performance itself is not impacted by the provided solution; however, it necessitates modifications in the solutions that utilise the service accounts, should there be any instances of renaming or hardcoded access keys in the affected services which smust be migrated because is a non-secure and poor practice. Should the migration not be executed properly, disruptions may occur.
Developer Impact
The impact for developers involves the necessity to make adjustments to their solutions that rely on service accounts. They might need to update systems to accommodate new naming conventions or replace hardcoded access keys. Furthermore, meticulous attention is required during migration to prevent potential service disruptions. Developers must ensure that their integrations and applications are compliant with the updated requirements to maintain smooth operation and avoid service interruptions.
Deployment
The deployment of the monitoring service carried out by the Security Engineering team requires its implementation in the AWS account managed by the team using Terraform Scripts. Resource standardisation and tagging are conducted using version control and Terraform scripts by the platform and development teams.
Dependencies
- Security Engineering requires monitoring permissions within GCP projects and AWS accounts to collect metrics, identify non-compliant service accounts, and acquire owner information, which ought to be supplied by the Cloud Provider owners within the technology team.
- There needs to be a formal agreement between the Technology and Security departments to implement the documented blueprint as an essential, routine business task to ensure the effective management of service accounts.