Skip to content

Commit 2608de5

Browse files
jonathanfrappierjonathanfrappier
authored
Add IAM to secure systems (#956)
🎫 [Jira task](https://hashicorp.atlassian.net/browse/WAF-385) 🔍 [Preview](https://unified-docs-frontend-preview-2i3p3l4lk-hashicorp.vercel.app/well-architected-framework/secure-systems/identity-access-management/define-access-requirements) + other pages under iam.
2 parents 8e2de1e + ad2d53c commit 2608de5

File tree

8 files changed

+755
-0
lines changed

8 files changed

+755
-0
lines changed

‎content/well-architected-framework/data/docs-nav-data.json‎

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -268,6 +268,39 @@
268268
}
269269
]
270270
},
271+
{
272+
"title": "Identity and access management",
273+
"routes": [
274+
{
275+
"title": "Define access requirements",
276+
"path": "secure-systems/identity-access-management/define-access-requirements"
277+
},
278+
{
279+
"title": "Grant least privilege",
280+
"path": "secure-systems/identity-access-management/grant-least-privilege"
281+
},
282+
{
283+
"title": "Create permissions and guardrails",
284+
"path": "secure-systems/identity-access-management/create-permissions-guardrails"
285+
},
286+
{
287+
"title": "Centralize identity management",
288+
"path": "secure-systems/identity-access-management/centralize-identity-management"
289+
},
290+
{
291+
"title": "Implement strong sign-in workflows",
292+
"path": "secure-systems/identity-access-management/implement-strong-sign-in-workflows"
293+
},
294+
{
295+
"title": "Use dynamic credentials",
296+
"path": "secure-systems/identity-access-management/use-dynamic-credentials"
297+
},
298+
{
299+
"title": "Manage access lifecycle",
300+
"path": "secure-systems/identity-access-management/manage-access-lifecycle"
301+
}
302+
]
303+
},
271304
{
272305
"title": "Secure applications",
273306
"routes": [

‎content/well-architected-framework/docs/docs/secure-systems/identity-access-management/centralize-identity-management.mdx‎

Lines changed: 95 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,95 @@
1+
---
2+
page_title: Centralize identity management
3+
description: Centralize identity management to manage access and improve security.
4+
---
5+
6+
# Centralize identity management
7+
8+
Designing and planning policies to manage access is part of a complete identity
9+
and access management strategy. A key part of that strategy is to centralize
10+
identity management, allowing you to enforce those policies effectively.
11+
12+
There are several ways to grant access to systems. Most systems have built-in
13+
identity solutions that allow you to create local users and groups. Those users
14+
and groups only have access to that specific system. While isolated identity
15+
management may seem secure, it does not scale well and may introduce more
16+
security risks than centralizing identity management.
17+
18+
## What is centralized identity management
19+
20+
Centralizing identity management allows you to manage access to all systems
21+
from a single location. Solutions like LDAP, Active Directory, or cloud identity
22+
providers like Okta, Azure EntraID, or Google Cloud Identity provide a way to
23+
centralize identity management. After you centralize authentication, you then
24+
integrate the identity provider with other systems and authorize access for those
25+
users. Each user has a single username and password, but can access the systems
26+
required to perform their job.
27+
28+
Having individual user accounts on multiple platforms is similar to having a
29+
local user on your laptop. You can log in to the laptop with the local user, but
30+
that username and password do not provide access to your email or other systems.
31+
32+
## Why centralize identity management
33+
34+
When you manage your users through a centralized
35+
identity provider, you can enforce strong security policies like multi-factor
36+
authentication (MFA), password complexity, and rotation policies.
37+
38+
From an end user perspective, centralizing identity management provides a
39+
single sign-on (SSO) experience, allowing users to access the systems they need
40+
with a single set of credentials. Using SSO reduces the risk of password
41+
fatigue and improves security by reducing the number of passwords that users
42+
need to remember.
43+
44+
You can deploy HashiCorp Vault to support centralized identity management by:
45+
46+
- **Act as an OIDC provider** - Deploy Vault as an OIDC provider gives you
47+
complete control over your identity management workflow and allows you to
48+
expose the OIDC provider based on your security requirements.
49+
- **Generate credentials** - Generate dynamic, short-lived credentials that
50+
eliminate static passwords stored in different systems.
51+
52+
Boundary provides identity-aware proxying to infrastructure without exposing
53+
credentials to end users:
54+
55+
- **Integrate with identity providers** - Connect Boundary to OIDC providers or
56+
Active Directory to authenticate users based on their existing corporate
57+
identities.
58+
- **Role-based access control** - Map users and groups from your identity
59+
provider to Boundary roles, controlling which systems each user can access.
60+
- **Session recording and auditing** - Track which users accessed which systems,
61+
creating an audit trail tied to real identities rather than shared
62+
credentials.
63+
64+
Most HashiCorp tools and services like the [HashiCorp Cloud
65+
Platform](https://portal.cloud.hashicorp.com/sign-in), HCP Terraform, Boundary,
66+
and Vault integrate with third party identity providers natively or through
67+
OIDC allowing you to manage access to these tools from your centralized identity
68+
provider.
69+
70+
HashiCorp resources:
71+
72+
- [Use Vault as an OIDC provider for single sign-on](/nomad/tutorials/archive/sso-oidc-vault)
73+
- [Vault as an OIDC identity provider](/vault/docs/secrets/identity/oidc-provider)
74+
75+
External resources:
76+
77+
- [NIST SP 800-63 Digital Identity Guidelines](https://pages.nist.gov/800-63-3/sp800-63c.html)
78+
79+
## Next steps
80+
81+
Following these documents in order ensures a logical progression through the key
82+
concepts and best practices, helping you build a strong foundation to build your
83+
identity and access management program.
84+
85+
- [Define access requirements](/well-architected-framework/secure-systems/identity-access-management/define-access-requirements)
86+
- [Grant least privilege](/well-architected-framework/secure-systems/identity-access-management/grant-least-privilege)
87+
- [Create permissions and guardrails](/well-architected-framework/secure-systems/identity-access-management/create-permissions-guardrails)
88+
- **Centralize identity management (this document)**
89+
- [Implement strong sign-in workflows](/well-architected-framework/secure-systems/identity-access-management/implement-strong-sign-in-workflows)
90+
- [Use dynamic credentials](/well-architected-framework/secure-systems/identity-access-management/use-dynamic-credentials)
91+
- [Manage access lifecycle](/well-architected-framework/secure-systems/identity-access-management/manage-access-lifecycle)
92+
93+
In this section of Identity and access management you learned the benefits
94+
of centralizing identity management. Identity and access management is part of the
95+
[Secure systems](/well-architected-framework/secure-systems) pillar.

‎content/well-architected-framework/docs/docs/secure-systems/identity-access-management/create-permissions-guardrails.mdx‎

Lines changed: 118 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,118 @@
1+
---
2+
page_title: Create permissions and guardrails
3+
description: Write effective identity and access management (IAM) policies that enforce permissions guardrails by using least privilege.
4+
---
5+
6+
# Create permissions and guardrails
7+
8+
Once you have defined your access requirements, you can begin writing
9+
policies that enforce permissions guardrails by using [least
10+
privilege](/well-architected-framework/secure-systems/identity-access-management/grant-least-privilege)
11+
policies.
12+
13+
Creating policies and enforcing guardrails is the process of translating
14+
requirements into policies that define what users, applications, and systems can
15+
do. Writing effective permissions involves converting the requirements for each
16+
role or function within your organization when you [defined your access
17+
requirements](/well-architected-framework/secure-systems/identity-access-management/define-access-requirements)
18+
into policies for your systems.
19+
20+
## What are permissions
21+
22+
Permissions are the specific actions that users, applications, or systems can
23+
take on resources. Permissions are typically defined in policies and used to
24+
control access to resources in a system.
25+
26+
You can grant or deny permissions based on various factors, including the user's
27+
role, group membership, the resources they access, and the context of the access
28+
request. For example, a user may have permission to read data from a database
29+
but not to write data to it.
30+
31+
The following is an example of a database permission and AWS S3 bucket policy
32+
that follows least privilege:
33+
34+
<CodeBlockConfig hideClipboard>
35+
36+
```plaintext
37+
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly_user;
38+
```
39+
40+
</CodeBlockConfig>
41+
42+
The PostgreSQL role `readonly_user` with the `SELECT` permission can select data from
43+
tables, but not write or modify data.
44+
45+
An example AWS IAM policy that follows least privilege allows read-only access
46+
to download files from the "company-reports" S3 bucket.
47+
48+
```json
49+
{
50+
"Version": "2012-10-17",
51+
"Statement": [
52+
{
53+
"Effect": "Allow",
54+
"Action": [
55+
"s3:GetObject",
56+
"s3:ListBucket"
57+
],
58+
"Resource": [
59+
"arn:aws:s3:::company-reports",
60+
"arn:aws:s3:::company-reports/*"
61+
]
62+
}
63+
]
64+
}
65+
```
66+
67+
## Define permissions as code
68+
69+
Where possible, define your permissions in policies as code. Defining
70+
permissions in policies as code allows you to version control your policies,
71+
track changes over time, and collaborate with your team. You can then use tools like
72+
HashiCorp's Terraform or Red Hat's Ansible to deploy and update your policies.
73+
Most systems support writing policies in JSON, YAML, or XML.
74+
75+
<VideoEmbed url="https://www.youtube.com/watch?v=cOOw4d_6WyA"/>
76+
77+
Some systems like HashiCorp's Vault and Sentinel support policies in custom languages like
78+
the HashiCorp Configuration Language (HCL). JSON is another widely supported
79+
format. HashiCorp Vault supports JSON based policies, in addition to HCL. AWS
80+
Identity and Access Management (IAM) supports JSON-based policies. Other systems
81+
like Active Directory may require scripting the policies in other languages like
82+
PowerShell to create Group Policy Objects (GPOs).
83+
84+
Terraform helps you manage your policies for supported tools and services,
85+
allowing you to define, update, and enforce policies as code. Using automation
86+
to manage policies ensures that your policies are consistent, auditable, and can
87+
be version controlled.
88+
89+
HashiCorp resources:
90+
91+
- [Access controls with Vault policies](/vault/tutorials/policies/policies)
92+
- [Policy as code with Sentinel](/sentinel/docs/concepts/policy-as-code)
93+
- [Create IAM policies with Terraform](/terraform/tutorials/aws/aws-iam-policy)
94+
- [Use templates with Waypoint](/waypoint/tutorials/hcp-waypoint/use-template)
95+
96+
External resources:
97+
98+
- [Define, update, share, and enforce policies using code](https://developer.ibm.com/articles/policy-as-code-ansible-automation-engine-and-open-policy-agent/)
99+
- [Introduction to policy as code with automation](https://www.redhat.com/en/blog/policy-as-code-automation)
100+
101+
## Next steps
102+
103+
Following these documents in order ensures a logical progression through the key
104+
concepts and best practices, helping you build a strong foundation to build your
105+
identity and access management program.
106+
107+
- [Define access requirements](/well-architected-framework/secure-systems/identity-access-management/define-access-requirements)
108+
- [Grant least privilege](/well-architected-framework/secure-systems/identity-access-management/grant-least-privilege)
109+
- **Create permissions and guardrails (this document)**
110+
- [Centralize identity management](/well-architected-framework/secure-systems/identity-access-management/centralize-identity-management)
111+
- [Implement strong sign-in workflows](/well-architected-framework/secure-systems/identity-access-management/implement-strong-sign-in-workflows)
112+
- [Use dynamic credentials](/well-architected-framework/secure-systems/identity-access-management/use-dynamic-credentials)
113+
- [Manage access lifecycle](/well-architected-framework/secure-systems/identity-access-management/manage-access-lifecycle)
114+
115+
In this section of **Identity and access management**, you learned the
116+
difference between granting excessive permission and how it relates to the
117+
concept of least privilege. Identity and access management is part of the
118+
[Secure systems](/well-architected-framework/secure-systems) pillar.

‎content/well-architected-framework/docs/docs/secure-systems/identity-access-management/define-access-requirements.mdx‎

Lines changed: 103 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,103 @@
1+
---
2+
page_title: Define access requirements
3+
description: Identify and collect requirements to help you identify access requirements for your systems.
4+
---
5+
6+
# Define access requirements
7+
8+
Defining access requirements for your organization is an important step in
9+
creating secure systems. Identifying what requirements you need to implement can
10+
seem overwhelming. There are steps you can take to simplify identifying the
11+
requirements you need and collecting the necessary documentation to implement
12+
the access requirements.
13+
14+
## What are access requirements
15+
16+
Every system you interact with today includes a set of access requirements. These
17+
requirements define who can access the system, what actions they can take, and
18+
under what conditions they can access the system. Access requirements come from
19+
several sources, including:
20+
21+
- Industry regulations that define role-based access controls or separation of
22+
duties requirements (PCI, HIPAA).
23+
- Local, federal, or international regulatory standards that define data privacy
24+
and protection (CCPA, Sarbanes-Oxley, GDPR).
25+
- Current best operational practices that define security controls (SOC 2, NIST,
26+
ISO 27001).
27+
28+
When you understand which regulations and standards apply to your organization, you can
29+
begin to identify the specific access requirements that you need to implement
30+
for your systems and teams.
31+
32+
## How to define access requirements
33+
34+
Start by identifying the regulations and standards that apply to your
35+
organization from both an industry and geographic perspective. These regulations
36+
often align with specific security practices, such as [NIST SP
37+
800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) for access control.
38+
39+
Once you have identified and collected the requirements that apply to your
40+
organization, you need to document those requirements and begin mapping the
41+
specific access controls to your systems and teams. Documenting these
42+
requirements helps you ensure that you are meeting the necessary regulations and
43+
standards.
44+
45+
You should also designate a group responsible for staying up-to-date on changes to
46+
regulations and standards that may affect your access requirements. When
47+
regulations, standards, or best practices change, you need to update your access
48+
requirements accordingly. The group responsible for staying up-to-date on
49+
regulation updates evangelizes the need for strong security practices across
50+
your organization.
51+
52+
Documenting and maintaining your access requirements helps you ensure that you
53+
can meet audit requirements, such as those for SOC 2 or ISO 27001. Auditors will
54+
want to see that you have a clear understanding of your access requirements and
55+
that you are implementing the necessary controls to meet those requirements.
56+
57+
As you begin defining your access requirements, also think about how you can
58+
manage these controls at scale. HashiCorp's Terraform helps you deploy [policies
59+
as code](/well-architected-framework/secure-systems/compliance-and-governance/policy-as-code)
60+
such as policies for Vault or Sentinel to manage access controls across your
61+
systems.
62+
63+
[Project
64+
infragraph](https://www.hashicorp.com/en/blog/building-intelligent-infrastructure-automation-with-hashicorp),
65+
announced at HashiConf 2025, is a real-time infrastructure graph that provides
66+
visibility into your infrastructure and its relationships. By understanding
67+
relationships between your resources, you can better define and manage access
68+
requirements.
69+
70+
You can apply to our private beta for project infragraph
71+
[here](https://www.hashicorp.com/en/project-infragraph-private-beta).
72+
73+
HashiCorp resources:
74+
75+
- [Access controls with Vault policies](/vault/tutorials/policies/policies)
76+
- [Policy as code with Sentinel](/sentinel/docs/concepts/policy-as-code)
77+
- [Create IAM policies with Terraform](/terraform/tutorials/aws/aws-iam-policy)
78+
- [Use templates with Waypoint](/waypoint/tutorials/hcp-waypoint/use-template)
79+
80+
External resources:
81+
82+
- [NIST cybersecurity framework](https://www.nist.gov/cyberframework)
83+
- [Define, update, share, and enforce policies using code](https://developer.ibm.com/articles/policy-as-code-ansible-automation-engine-and-open-policy-agent/)
84+
- [Understanding separation of duties](https://www.pingidentity.com/en/resources/blog/post/separation-of-duties.html)
85+
86+
## Next steps
87+
88+
Following these documents in order ensures a logical progression through the key
89+
concepts and best practices, helping you build a strong foundation to build your
90+
identity and access management program.
91+
92+
- **Define access requirements (this document)**
93+
- [Grant least privilege](/well-architected-framework/secure-systems/identity-access-management/grant-least-privilege)
94+
- [Create permissions and guardrails](/well-architected-framework/secure-systems/identity-access-management/create-permissions-guardrails)
95+
- [Centralize identity management](/well-architected-framework/secure-systems/identity-access-management/centralize-identity-management)
96+
- [Implement strong sign-in workflows](/well-architected-framework/secure-systems/identity-access-management/implement-strong-sign-in-workflows)
97+
- [Use dynamic credentials](/well-architected-framework/secure-systems/identity-access-management/use-dynamic-credentials)
98+
- [Manage access lifecycle](/well-architected-framework/secure-systems/identity-access-management/manage-access-lifecycle)
99+
100+
In this section of Identity and access management, you learned the importance
101+
of identifying and collecting access requirements from common sources such as
102+
industry and regulatory standards. Identity and access management is part of the
103+
[Secure systems](/well-architected-framework/secure-systems) pillar.

0 commit comments

Comments
 (0)