LatestBest Practices for Identifying and Securing Non-Human Identities
Resource / Online Journal
Comprehensive Guide to Oracle Cloud Infrastructure Identity Access Management Concepts
Learn how Oracle Cloud Infrastructure (OCI) IAM enables secure identity management with fine-grained access controls, policy enforcement, authentication, monitoring, and integration with external tools like SailPoint and Saviynt for enhanced governance and compliance.
Published on Mar 5, 2025
Access Management
Executive Summary
OCI IAM enables secure and scalable identity management in Oracle Cloud Infrastructure with fine-grained access controls. This guide covers policy management, user and NHI administration, authentication, monitoring, and privileged access.
Key recommendations include leveraging native tools such as Oracle Cloud Guard for enforcing security guardrails and detecting misconfigurations, OCI Audit for tracking identity-related activities, and terraform for scalable and consistent policy deployment. External tools like SailPoint, Saviynt, and ARCON enhance governance and compliance.
By integrating OCI’s native tools with external solutions and TechDemocracy’s custom connectors, organizations can strengthen identity governance, authentication, and threat detection for secure cloud operations.
Oracle Cloud Infrastructure (OCI) Identity Access Management (IAM) Concepts
Account Attributes
1.OCI IAM Concepts
A tenancy is the fundamental unit of ownership and isolation in OCI, similar to an AWS account. It contains all resources, compartments, and associated policies for the enterprise. For instance, a bank operates all its cloud resources within its tenancy named BankTenancy.
An organization in OCI refers to the enterprise managing cloud operations through a single tenancy, similar to AWS Organizations. For example, a bank may have multiple OCI tenancies across different sub-units in a single organization.
A compartment is a logical container within a tenancy for organizing resources and enforcing fine-grained access control. For instance, a bank might have compartments for Insurance, Retail Banking, and Investment Banking.
A user is an identity in a tenancy used for authentication and authorization, assigned to groups for policy-based access. For example, jane.doe@bank.com in the Finance Team group can access financial data.
A group is a collection of users for centralized policy management. For instance, the Database Admins group has permissions to manage database services across compartments.
A policy defines access rules for users, groups, and dynamic groups. For example, a policy may allow the App Development group to manage resources in DevCompartment.
A dynamic group is a rule-based collection of resources (e.g., compute instances) for automated policy application. For example, instances tagged Environment=Production can be grouped to access specific APIs.
A tag is a metadata key-value pair applied to resources for organizational and access purposes. For instance, CostCenter=Marketing helps enforce access policies or track marketing-related billing.
Unlike traditional identity stores, OCI IAM does not natively store user attributes like first or last name unless explicitly defined in an external identity provider (IdP). Instead, each OCI IAM user has the following attributes:
1. User OCID: A globally unique identifier for a user in OCI, formatted as an Oracle Cloud Identifier (OCID).
Example: ocid1.user.oc1..aaaaaaaaexampleuserid
2. Email Address: The primary unique identifier for a user in the tenancy, used for login and notifications.
Example: john.doe@bank.com
3. Federated Identity (if applicable): When federated with an external IdP (e.g., Okta, Azure AD), the user is authenticated via the external provider and mapped to OCI roles. Example: A federated user authenticated through Okta is assigned roles in OCI based on their IdP group.
4. Creation Time: The timestamp indicating when the user account was created in OCI IAM.
Example: 2025-01-01T10:00:00Z
5. Tags (Optional): Key-value metadata pairs for categorizing users.
Example: FirstName=Jane, LastName=Doe, Department=Finance
6. Authentication Factors: These attributes are required if authentication is not delegated to an external IdP:
a. Password: Used for console login with configurable policies (e.g., complexity, expiration).
b. MFA Configuration: Set up via OCI's MFA options like OTPs, push notifications, or hardware tokens (e.g., YubiKey).
7. Last Activity Time: Tracks the user's most recent activity (e.g., Console login, API call) to identify dormant accounts.
Example: LastLogin=2025-01-25T12:34:56Z
8. Tenancy Membership: Indicates the user’s association with the tenancy, where users are created and managed. Permissions are assigned via groups and policies. Example: john.doe@bank.com belongs to GlobalBankTenancy.
9. Credential Types: Includes API keys, Auth Tokens, and SSL Certificates for programmatic authentication, which should be securely stored in OCI Vault. Example: An API key generated for programmatic access is stored securely in a secret management tool.
3. Entitlement Types & Their Attributes
| Policy Assignment | Policy Name, Principal (User/Group/Dynamic Group), Scope (Compartment/Tenancy) | A policy in OCI IAM specifies the actions users, groups, or dynamic groups can take on resources. For example, a policy can allow the Finance Team group to manage budgets in the Finance Compartment: Allow group Finance Team to manage budgets in compartment Finance Compartment. |
| Group Membership | Group Name, Assigned Policies | Logical grouping of users for collective policy assignments. Example: Add john.doe@bank.com to the group DatabaseAdmins, and assign the group a policy to manage databases: Allow group DatabaseAdmins to manage databases in compartment Production. Groups simplify permission management by aligning organizational roles with access needs. |
| Identity-Based Policy | Policy Name, Principal (User/Group/Dynamic Group), Scope | Identity-based policies define what actions an identity can perform on resources within a specific compartment or tenancy. Example: Grant a policy to the user jane.doe@bank.com to view audit logs in the AuditCompartment: Allow user jane.doe@bank.com to read audit-log in compartment AuditCompartment. |
| Resource-Based Policy | Resource (e.g., Object Storage Bucket, VCN), Principal, Policy | Policies attached directly to a resource for granting access to external principals. Example: Grant a group in another tenancy permissions to read an Object Storage bucket: Allow group ExternalReaders from tenancy ocid1.tenancy.oc1..exampleid to read objects in bucket SalesDataBucket. Resource-based policies are not recommended in OCI because compartment-level policies and dynamic groups provide sufficient flexibility to manage access. They offer better scalability, central governance, and reduced complexity compared to attaching policies directly to resources. |
| Compartment Policies | Scope (Compartment), Policy Rules | Compartment policies define access rules at the compartment level for users or groups. Example: Grant the AppTeam group permissions to manage all resources in a compartment: Allow group AppTeam to manage all-resources in compartment DevelopmentCompartment. |
| Dynamic Groups | Rule-Based Membership, Assigned Policies | Instead of specifying a static list of resources in a policy, a dynamic group allows you to define query criteria for resources based on their attributes, and all resources that meet the criteria are automatically included in the group. For example, you can create a dynamic group for Object Storage buckets in OCI that belong to the staging environment, using a query like: All buckets in the compartment "StagingCompartment" with the tag "Environment=Staging". This ensures that any current or future bucket matching this criteria is automatically included in the group and inherits the assigned policies. |
| Organization Policies | Constraints (e.g., Regions, Services, Network Configurations) | Define global guardrails for compartments and resources within a tenancy. The organization level (tenancy) in OCI is used for negative guardrails, preventing mistakes by restricting actions globally, such as disallowing the creation of resources in certain regions (e.g., "No resources can be created in the us-ashburn-1 region"). The compartment provides a scalable way to define access policies once and ensure they inherit to all resources within the compartment, such as granting the "Dev Team" access to manage all storage buckets in the DevelopmentCompartment. |
| IAM Conditions | Attribute-Based Conditions (Time, IP, Resource Tags, Device) | Add fine-grained conditions to policies. Example: Grant access to an Object Storage bucket only from specific IP ranges: Allow group DataTeam to read objects in compartment DataCompartment where request.networkSource.name = 'TrustedIPRange'. |
| Service Account Permissions | Service Principal, Policy Rules, Scope | Assign permissions to service principals (e.g., instance principals) for workload operations. Example: Allow an instance in DevelopmentCompartment to manage Block Volumes: Allow instance-principals to manage volumes in compartment DevelopmentCompartment. |
| Workload Identity Federation | Identity Provider (IdP), Dynamic Group, Policy | Allow external workloads (e.g., on-prem apps or AWS Lambda) to securely access OCI resources. Example: Configure Workload Identity Federation to allow an AWS Lambda function to access OCI Object Storage through a dynamic group: Allow dynamic-group ExternalApp to read objects in compartment SharedStorage. |
Recommendations
Policy Recommendations
Policies Included: Identity-Based Policies, Resource-Based Policies, IAM Conditions, Tags and Labels, Organization Policies, Role Definitions.
Options for Configuration:
| OCI Native Tools | Description |
|---|---|
| OCI Console, CLI, REST API, or Terraform | Used to define and manage policies for scalability, automation, and governance. |
| Dynamic groups and assign policies | Create dynamic groups and assign policies to enable programmatic access control. |
| Oracle Cloud Guard | Leverage to monitor and enforce Org Policies, detect misconfigurations, and identify anomalous behavior across the tenancy. |
| External Products | Description |
|---|---|
| IGA Tools (e.g., SailPoint, Saviynt) | Centralize governance for identity-based policies, role definitions, and access reviews, ensuring compliance in OCI environments. |
| CNAPP Tools (e.g., AccuKnox) | Provide visibility, enforcement of resource-specific policies, workload protection, and compliance monitoring in OCI. |
| CWPP Tools (e.g., AccuKnox) | Manage and enforce dynamic group policies, resource-level configurations, and secure OCI workloads through container and workload security. |
Aggregation Entities Administration Recommendations
Scope: Organization, Project, Folder, Tenancy Definitions, Org-Level Guardrails (Org Policies).
Options for Configuration:
| OCI Native Tools | Description |
|---|---|
| OCI Console | Use the OCI Console to create and manage organizations, projects, folders, tenancies, and organizational policies. Ideal for smaller-scale setups or one-off configurations. |
| OCI CLI | Automate the creation of organizations, projects, folders, and tenancies using the OCI CLI for scripting and repetitive tasks. |
| OCI API | Integrate OCI API calls into workflows to dynamically create and manage organizations, projects, folders, and tenancies, ensuring scalability and governance. |
| Terraform | Use Infrastructure-as-Code (IaC) to define and deploy organizations, projects, folders, and tenancies, ensuring auditability, version control, and seamless CI/CD integration. |
| Oracle Cloud Guard | Monitor and enforce Org Policies to detect and remediate misconfigurations and compliance violations across the tenancy. |
| External Products | Description |
|---|---|
| IGA Tools (e.g., SailPoint, Saviynt) | Centralize governance for roles, organizational policies, and project/folder management in OCI, enabling role provisioning, policy governance, and periodic reviews. |
| CSPM Tools (e.g., Check Point CloudGuard) | Monitor and enforce Org Policies and compliance guardrails across the tenancy, ensuring best practices for configuration and governance. |
User Administration
Scope: User Account Creation, User Group Assignments, and Identity Policy Assignments to Users.
Options for Configuration:
| OCI Native Tools | Description |
|---|---|
| OCI Console, OCI CLI, OCI API, or Terraform | Use these tools to create and manage groups, roles, and policy assignments for human users, ensuring scalability, automation, and auditability. |
| External Products | Description |
| IGA Tools (e.g., SailPoint, Saviynt) | Enable centralized governance for group creation, management, and policy assignments, and workflow implementation with periodic reviews. |
| CNAPP Tools (e.g., Palo Alto Prisma Cloud, Wiz, Orca Security) | Offer visibility into misconfigured IAM roles and support roles and policy assignment audits for cloud-native environments. |
| CSPM Tools (e.g., Prisma Cloud by Palo Alto Networks) | Extend support to OCI, offering comprehensive cloud-native security, including insights into misconfigured IAM roles and roles and policy assignment audits for cloud-native environments. |
PAM (Privileged Account Monitoring)
Scope: Monitor and manage Break The Glass Activities, Emergency Assignments, Privileged Session Recording, Shared Accounts Administration, and Break The Glass Account Administration.
Options for Configuration:
| OCI Native Tools | Description |
|---|---|
| Oracle Privileged Account Manager (OPAM) | Centralizes password management for privileged and shared accounts, enabling policy-based checkout/check-in, automatic password rotation, and auditing for enhanced security. |
| Oracle Identity and Access Management (IAM) | Provides user authentication, authorization, and auditing, enabling privileged access management within OCI through configurable policies and controls. |
| External Products | Description |
|---|---|
| ARCON Privileged Access Management (PAM) | Integrates with Oracle Access Governance to centralize privileged account control, automate governance, streamline access reviews, and enforce security policies. |
| Britive | A cloud-native privileged access management (PAM) solution that provides secure, dynamic access for modern cloud environments, including Oracle Cloud Infrastructure (OCI). |
Note
Determining which OCI accounts should be scoped for PAM involves:
Policies & Permissions: Prioritize accounts with high-risk permissions (e.g., resource provisioning, compartment management). Read-only accounts may not need PAM.
Application Classification: Assess compliance needs, risk severity, and business criticality.
Nature of the Account: Evaluate named users, shared accounts, break-glass, and service accounts for associated risks.
Frequency & Scope: Apply PAM to rare, high-impact activities like emergency privilege escalation or break-glass scenarios, while frequent, low-risk actions may not require it.
This approach ensures PAM is applied where needed, securing high-risk activities while avoiding unnecessary complexity.
NHI Administration
Scope: Service Account Permissions.
Options for Configuration:
| OCI Native Tools | Description |
|---|---|
| OCI IAM, CLI, API, or Terraform | These tools are used to create and manage service accounts (Instance Principals or Dynamic Groups) and assign permissions via policies for scalability and governance. |
| External Tools | Description |
|---|---|
| NHI Governance Tools (e.g., Natoma, Veza, Astrix) | Automate service account governance, including secure credential storage, role assignments, credential rotation, and Zero Trust enforcement. TechDemocracy can develop custom OCI integrations if direct connectors are unavailable. |
| IGA Tools (e.g., SailPoint, Saviynt) | Implement workflows for service account permissions, including approval processes, periodic reviews, and compliance tracking to align with OCI IAM policies. Custom OCI integrations can be developed if needed. |
A Note on Role vs NHI
Service Account-Based Approach (Static Credentials)
A service account is created in OCI, and its private key or instance principal credentials are shared with the consuming program.
Example: A Compute Instance Principal Accesses Object Storage using a policy with read and write permissions.
Federation-Based Approach (Dynamic Authentication)
Instead of sharing credentials, federation is configured to allow external identities (e.g., Azure AD roles, AWS IAM roles) to authenticate and impersonate the OCI service account.
Example: An AWS Lambda function federates with OCI to access Object Storage via a dynamic group policy.
Hybrid Defense-In-Depth Approach
Implements Zero Trust Architecture principles by layering security:
Create the service account: Assign necessary permissions to the Service Account and securely store its credentials in OCI Vault.
Use workload federation: Configure for a separate account with, limited-permission service account to access the credential store.
Retrieve credentials securely: The federated Service Account retrieves high-privilege credentials securely from OCI Vault.
Automate credential rotation: Use OCI automation tools or custom scripts to enhance security.
Authentication
Scope: Enable secure access using Federation, Single Sign-On (SSO), and Multi-Factor Authentication (MFA) for robust and scalable identity authentication, including passwordless authentication options.
Options for Configuration:
| OCI Native Tools | Description |
|---|---|
| Oracle IAM or IDCS | Use these tools for centralized, passwordless authentication and IdP integration. |
| External Tools | Description |
|---|---|
| SSO and Federation Tools (e.g., Okta, Ping Identity, Microsoft Entra ID) | Enable centralized identity federation and SSO for secure OCI access and third-party applications. |
| MFA Tools (e.g., Duo Security, YubiKey, Microsoft Authenticator) | Enhance security with MFA using push notifications, biometrics, hardware tokens and and passwordless authentication. |
| Passwordless Authentication Tools (e.g., Beyond Identity, Ping Identity, HYPR) | Enable password-free OCI access using biometrics, device trust, and cryptography. |
Monitoring, Detection, and Response Recommendations
Scope: Log storage, event and incident detection, and incident response for cloud security and governance.
Options for Configuration:
| OCI Native Tools | Description |
|---|---|
| Use OCI Logging, OCI Monitoring, OCI Audit and OCI Cloud Guard |
| External Products | Description |
|---|---|
| Identity Governance and Administration (IGA) Tools | SailPoint: Offers integration capabilities with various security solutions, including CrowdStrike, to enhance identity risk management. Saviynt: Provides out-of-the-box integrations and the flexibility to develop custom connectors, facilitating comprehensive identity governance within OCI. |
| Identity Threat Detection and Response (ITDR) Tools | CrowdStrike Falcon: Integrates with identity governance platforms like SailPoint to monitor and respond to identity-related threats, such as compromised credentials and unauthorized access. SentinelOne Singularity Identity: Provides identity threat detection and response capabilities, with integration options that can be extended to OCI through custom connectors developed by TechDemocracy. |
| Non-Human Identity Threat Detection and Response (NHITDR) Tools | Astrix Security: Focuses on detecting and mitigating threats targeting service accounts by monitoring for abnormal behaviors and unauthorized API calls. Custom connectors can be developed to integrate Astrix Security with OCI environments. Entro: Specializes in securing machine identities and can be integrated into OCI through custom connector development, enhancing the security of service accounts and automated processes. |
Decision Making
How to Make a Strategic Approach to NHI Governance and Security
Developing a robust Non-Human Identity (NHI) Governance, Activity Monitoring, and Detection & Response strategy requires a balanced approach to risk, compliance, security, tools, and processes. TechDemocracy’s proven Cloud Security Decision Framework, trusted by Fortune 100 companies, simplifies complex decisions, ensuring tailored and effective security solutions.
1. Risk, Compliance, and Security Context
Risk Tolerance: Align security strategy with business goals and acceptable risk levels.
Audit & Compliance: Ensure adherence to regulations, identify gaps, and improve compliance efforts.
Risk Classification: Categorize workloads by sensitivity (critical, high-risk, low-risk) to prioritize security and monitoring.
2. Landscape and Roadmap for Tools:
Current Landscape for Cloud Security and Detect and Respond:
a. Evaluate currently deployed tools, including CWAPP, CNAPP, CSPM, and other security platforms, in terms of:
a. Maturity: How well the tools are integrated and used.
b. Skillsets: The expertise available in managing and optimizing these tools.
c. Ownership and Responsibilities: Clear accountability for tool governance and maintenance.
d. Roadmap and Priorities: Plans for tool upgrades, expansions, or replacements to meet evolving needs.
Current Detect and Response Tools:
Assess your existing DR solutions (e.g., EDR, XDR, CDR) and SIEM tools for their effectiveness and integration capabilities.
Identify opportunities to enhance detection with ITDR and NHITDR solutions.
IDM Landscape:
Analyze deployments of IGA, PAM, NHI, SSO/MFA tools to ensure seamless integration and governance across your identity and access ecosystem.
Complexity and Effort in Data Synchronization and Integrations:
Evaluate the effort required to integrate AWS IAM and external tools (e.g., IGA, CNAPP, CSPM, ITDR), considering automation opportunities to reduce manual overhead.
3. Processes, Budget, and Ownership:
DevOps Maturity:
Assess the automation, scalability, and integration level in your DevOps processes to determine readiness for identity and security management solutions.
Organizational Structure and Responsibilities:
Understand ownership, budgets and accountability for:
a. Cloud Infrastructure: Who manages infrastructure setup and operations?
b. Cloud Security: Who governs cloud security tools and processes?
c. Security in DevOps: Who ensures CI/CD pipeline security and secure workload deployment?
d. Cloud Security Tools Deployment: Who oversees selecting, deploying, and maintaining security tools like CNAPP, CSPM, CWPP, and ITDR?
Conclusion
Successful OCI IAM implementation requires strategic policy management, user and NHI governance, and seamless tool integration with external tools to enhance security and compliance. Key considerations include risk tolerance, DevOps maturity, and security tool alignment.
Why TechDemocracy?
TechDemocracy designs secure, scalable cloud architectures tailored to your needs. Our Cloud Security Decision Framework helps align risk, compliance, and security goals while optimizing tools and integrations.
- Align risk, compliance, and security with operational needs.
- Optimize your tool landscape and roadmap.
- Streamline integrations, improve governance, and enhance processes.
We provide end-to-end architecture design, product selection, and implementation across all domains covered in this blog.
Partner with TechDemocracy, top cybersecurity solution provider to enhance your cloud security architecture, develop a robust strategy, and implement advanced solutions for identity governance, cloud security, and threat detection. Contact us now to build a strong, secure foundation for your cloud journey!
Recommended articles
Comprehensive Guide to AWS IAM: Policy Management, Authentication, & Access Strategy
Take Your Identity Strategy
to the Next Level
Strengthen your organization's digital identity for a secure and worry-free tomorrow. Kickstart the journey with a complimentary consultation to explore personalized solutions.