Environment Boundaries
Last updated
Last updated
Heeler helps you prioritize your analysis and response by providing business context. Environment Boundaries improve risk prioritization and impact, and enables Heeler's lifecycle management capability to track full resolution across all environments.
Heeler segments your resources into the following environments:
Production: An environment dedicated to running applications that serve end users and customers. Customer facing SaaS applications will run in the production environment.
Disaster Recovery: An environment to mitigate a disaster event that results in disruption or loss of primary environments.
Corporate: An environment dedicated to services and applications that serve general company needs rather than customer-facing applications. Corporate websites, HR systems, and other applications that support the daily operations of the organization run in the corporate environment.
Staging: A preproduction environment where you validate that the code and infrastructure perform as expected under production-equivalent circumstances. This environment is configured to be as similar as possible to the production environment.
Development: An environment where developers integrate their code to confirm that it all works as a single, cohesive application.
Test: An environment where Quality Assurance teams or acceptance testing takes place. Teams often do performance or integration testing in this environment.
Sandbox: An environment where developers write code, make mistakes, and perform proof of concept work.
Unassigned: A catch-all for resources that are not automatically curated into a defined Environment.
To provide a simpler context, Heeler also groups these Environments into High and Low impact:
High Impact: Production, Disaster Recovery, Corporate, Unassigned
Low Impact: Staging, Development, Test, and Sandbox
Unassigned is grouped with other environments as High Impact given that Unassigned resources could belong to Production, etc.
There are several ways Environments can be implemented. They are:
Organizational Units/Folders. This method is recommended as the simplest to implement and maintain. By assigning Organizational Units (OUs) /Folders to different Environments, entire accounts/projects and their resources can be managed by their relationship to the OUs/Folders. This method scales well as accounts and resources are added, whether organically or through acquisition.
Tags. This method works well if accounts/projects are not structured into OUs/Folders in a way that reflects their logical environment. This method leverages tagging at the account/project level to define the Environment of their resources. This method is easier to implement if there is an existing and enforced tagging strategy in place.
Accounts. This method is similar to OUs/Folders provided a) the accounts in scope are relatively stable, i.e., not a lot of accounts entering or leaving, b) they are a manageable in number, and 3) they are consistent in purpose., i.e., there are not Production and Development resources in the same account.
Resources. This method provides the most control over defining the Environment for individual resources. This method leverages tagging at the resource level for specific compute resources to define application Environment. It is more difficult to set up and maintain, but may be necessary if there are resources in different Environments in the same account/project.
The process for assigning resources to Environments is managed here:
If you select Organizational Units, you will see a listing of OUs and be able to add one or more OUs to the Production environment (in this example). Likewise, if you select Accounts,you will see a listing of accounts and be able to add one or more accounts to the Production environment. If the account is a member of an OU and that OU is assigned to a different environment, then the account setting will take precedence.
Finally, if you select Tags, you will see a modal like so:
If you leave Allow Resource Override unchecked, this option will implement the Tag option where the tags on accounts will define the Environment Tag for all of their resources. If you check Allow Resource Override, then this option will implement the Resource option, which is similar to Tag, but allows resources tagged with acceptable Environment Tags to override their account's Environment Tag.
Once tags and/or maps are in place, Environment and Impact are maintained automatically and they allow you to view findings and perform analysis more efficiently by focusing on what is important.
For example, this Infrastructure view shows Production resources allowing Cross Account Access
By selecting the filtered resources, you can learn more about the potential issue quickly and thoroughly.
The same pattern is available for Software Repositories. For example, this Software view shows Test repositories that have secret scanning disabled
