Log In Schedule a Live Demo Get Started

Permission Control for Third Parties

For years, organizations have recognized the importance of closely managing employee access using identity governance and administration solutions. More recently, they have come to realize that the same level of governance is essential for non-employees as well.   

A study sponsored by Opus and conducted by Ponemon found that 59 percent of companies reported data breaches caused by their vendors or third parties, many of which went unnoticed. 

With the increasing prevalence of third-party cybersecurity incidents, the management of non-employee access has become more critical than ever.  How can organizations ensure that non-employees can access the necessary resources to perform their duties while maintaining sufficient restrictions to prevent security risks?  

Cyberattacks through an organization’s vendors or suppliers

Organizations are dependent upon their third-party vendors to provide important services such as payroll, software development or data processing. However, without having strong security controls in place, vendors, suppliers, contractors or business partners can put organizations at risk for a third-party data breach. 

In addition, cyberattacks through an organization’s vendors or suppliers are greatly underreported. According to new research from Ponemon Institute and Mastercard’s RiskRecon, only 34% of organizations are confident their suppliers would notify them of a breach of their sensitive information.  

Why is permission control for third parties so complicated?

Companies are progressively relying more on third-party collaborations, sharing confidential and sensitive information with an average of 583 third parties. However, just 34 percent maintain a comprehensive record of these third-party relationships, with an even lower percentage, 15 percent, doing so for Nth parties. The primary reason, cited by 69 percent of respondents, for this lack of comprehensive inventory is the absence of centralized control. Other significant factors include a shortage of resources and the intricate nature of these third-party partnerships.

Moreover, less than half of all companies consider the management of risks associated with third-party relationships as effective and a top priority within their organization. A mere 37 percent claim to possess sufficient resources for managing these relationships, and only 35 percent rate their third-party risk management program as highly effective. Additionally, over half of the companies are uncertain whether their vendor safeguards are adequate to prevent a breach.  

“The third-party ecosystem is an ideal environment for cyber criminals looking to infiltrate an organization, and the risk only grows as these networks become larger and more complex,” said Dov Goldman, VP, Innovation & Alliances of Opus. “To stay ahead of the risk, companies and executives need to collaborate around plans for third-party detection and mitigation that supports automated technology and strong governance practices.”

No centralized control over third-party relationships 

Because accountability for the third-party risk management program is not centralized

within one function, it can create a barrier to having a comprehensive inventory of all third

parties. In the Ponemon study, only 34 percent of respondents say they have a comprehensive inventory of all their third parties. Of these respondents, 69 percent of respondents cite a lack of centralized control over third-party relationships as to why they do not have such an inventory. Almost half of respondents (48 percent) say complexity in third-party relationships is a barrier, as seen in the graph below.

You absolutely need to apply granular access controls around vendor access to enforce least privilege and meet many compliance requirements. You absolutely need to ensure best practices like password management and session auditing are implemented. These security controls are essential to mitigating the most common and dangerous vendor access attack vectors.

About Apono, Permission Control for Every User 

Apono is a granular permission control solution that offers fine-grained access policies to cloud assets. Apono integrates directly with the specific service or resource type. This allows us to  change the permissions at the resource level itself, for example a specific collection or table in your data repository instead of the entire cluster. Our solution allows for control of specific roles and permissions of each resource type and service from one central tool, bringing a unified privilege control plane to the admin, with workflows and audit capabilities on top.  

Granular Permission Control: Do Organizations Need it?

Permission Control

The modern workplace is constantly evolving, with organizations of all sizes needing to keep up with the ever-changing landscape. One essential part of ensuring a secure working environment is having the right permission control in place. 

Fine-grained permission control is a powerful tool for organizations to manage access and security within their networks and systems. By using this type of permission control, organizations can set restrictions on what type of data is accessible and by whom, helping to prevent unauthorized access or data breaches. Not only is this critical for keeping sensitive information safe, but it also helps to ensure that everyone in the organization is able to access the resources they need to do their job. 

What is Granular Permission Control?

Granular permission control is the ability to set and manage user access to different areas of a system at a highly specific level. It allows organizations to assign permissions on a per-user or per-role basis, ensuring that individuals only have access to the resources and information they need to perform their tasks. This level of control helps prevent unauthorized access and reduces the risk of data breaches. 

Smart granular permission control leverages native integrations to all critical services, apps, and data repositories and is able to grant permissions in as high or low of granularity as is required. 

For example, a self-hosted and cloud-hosted PostgreSQL, MySQL, and Mongo integration can manage access to clusters, databases, collections, schemas, and more, whereas traditional PAM solutions usually stop at the app level.

The Risks of Inadequate Permission Control

Without proper permission control, organizations face several risks. Unauthorized individuals may gain access to sensitive data, leading to data breaches and potential legal and financial repercussions. Inadequate permission control can also result in data loss, as users may accidentally delete or modify critical information. Additionally, organizations may experience a lack of accountability and traceability, making it difficult to track and monitor user activities. In summary, the risks of inadequate permission control include data breaches, data loss, and a lack of accountability.

Protecting Sensitive Data with Fine-Grained Permissions

One of the key benefits of fine-grained permission control is its ability to protect sensitive data. By granting access to specific users or roles, organizations can ensure that only those who need to see certain information have the ability to do so. This level of control significantly reduces the risk of data breaches and unauthorized access, providing peace of mind for both organizations and their clients. With fine-grained permissions, organizations can safeguard their sensitive data and maintain the confidentiality and integrity of their information.

Types of Permission Controls

1. Role-based access control. This is one of the most common forms of granular access control that limits access based on the user’s role in an organization. It works by associating each user with a particular role that defines their level of access rights to specific resources.

2. Attribute-based access control. ABAC assigns permissions based on user attributes such as location, time, or other contextual information.

3. Policy-based access control. PBAC is when each type of user is assigned a set of policies that define what they are allowed to do. When they attempt to access a resource, the system checks the policies to see if they are allowed to do so. If the user’s policies allow them to access said resource, they are granted access; if not, access is denied.

4. Resource-based access control. In a resource-based policy, the access control rules are associated with the resource itself, rather than being managed centrally by an authority or user.

Best Practices for Effective Fine-Grained Permission Management

To ensure effective fine-grained permission management, organizations should follow best practices. Firstly, it’s crucial to conduct a thorough audit of user access levels and permissions. This helps identify any inconsistencies or vulnerabilities. Secondly, organizations should adopt a least privilege principle, granting users the minimum access necessary to perform their tasks. 

It’s important to make sure the solution has the capabilities to dynamically grant and revoke permissions to all the critical resources and services to which it governs access. In addition, the solution should strive to offer robust and dynamic IFTTT scenarios, by leveraging context about on-call shifts, IdP groups, managers, work hours, and more to make sure Just-in-Time access is refined to the specific business use case.  

When looking for a solution, it’s important it is also able to integrate directly with the services and the changing of the permissions at the integration level itself and speak the policy language of each one, bringing a unified privilege control plane to the admin, with workflows and audit capabilities on top. Lastly, regularly training employees on data security practices will further enhance the effectiveness of fine-grained permission management. 

About Apono

Apono is a granular permission control solution that offers fine-grained access policies to cloud assets. Apono integrates directly with the specific service or resource type. This allows us to  change the permissions at the resource level itself, for example a specific collection or table in your data repository instead of the entire cluster. Our solution allows for control of specific roles and permissions of each resource type and service from one central tool, bringing a unified privilege control plane to the admin, with workflows and audit capabilities on top. Try us free!

IAM vs PAM: How are they different?

IAM vs PAM

The digital world has become a hub for organizational data and sensitive information. It is essential to manage this information and protect it from unwanted breaches and threats. That’s where cybersecurity and access control come into the picture. Privileged Access Management (PAM) and Identity and Access Management (IAM) are two crucial concepts that organizations must consider when securing their digital assets. 

Identity and access management (IAM) and privileged access management (PAM) are two related but distinct concepts that organizations use to manage their security policies and user access rights.     

IAM vs PAM 

PAM deals with providing privileged users, such as system administrators, database administrators, and IT managers, with access to sensitive information or assets. It controls the user’s actions and limits their access to only necessary information, thereby minimizing the risk of any potential breaches. In contrast, IAM manages user access to a company’s information and resources based on their role, job, or other relevant factors. IAM also enables the administrators to revoke access rights if they leave the company or change their roles.

To paint a more vivid picture, imagine a secure room in a building that contains critical company information. The PAM system will restrict access to this room and only allow specific individuals with proper authorization and clearance to enter the room. Furthermore, PAM would limit the authorized personnel’s time within the room, logging all their activities and actions to monitor their use. Conversely, the IAM system will limit the access of each employee within the company’s premises based on their job roles, only giving access to the information necessary to fulfill their job duties.

In conclusion, PAM and IAM serve different functions but are both vital in securing organizational data and assets. Understanding these concepts and their functionalities is crucial to ensure the safety and confidentiality of digital information. Organizations must ensure they adopt a suitable combination of PAM and IAM tools to control access to information effectively.

IAM vs PAM

IAM focuses on controlling access to a broader range of resources, such as applications, data, and services, for all types of users within an organization, from employees to partners, contractors, and customers. IAM solutions provide centralized and automated tools to manage user authentication, authorization, and identity provisioning, including password policies, single sign-on (SSO), multi-factor authentication (MFA), and role-based access control (RBAC). IAM is often integrated with other security systems and compliance frameworks, such as audit logs and identity governance, risk, and compliance (GRC).



Key features of IAM include:

  • User provisioning and de-provisioning: Managing user accounts and access privileges throughout their lifecycle, including onboarding, changes, and offboarding.
  • Authentication and authorization: Verifying the identity of users and granting them appropriate permissions based on their roles and responsibilities.
  • Single Sign-On (SSO): Allowing users to access multiple applications and services with a single set of credentials.
  • Multi-factor authentication (MFA): Enhancing security by requiring multiple forms of authentication.
  • Role-based access control (RBAC): Assigning permissions based on job roles or responsibilities.
  • Auditing and reporting: Monitoring and recording user access activities for compliance and security purposes.

PAM vs IAM

On the other hand, PAM deals with managing privileged or administrative access to critical systems, applications, and data, that are crucial for maintaining the IT infrastructure and operations. PAM solutions are designed to control and monitor the actions of privileged users, such as IT administrators, network engineers, and DevOps staff, who have extensive access to sensitive resources and can cause severe damage if misused or compromised. PAM tools provide features such as session recording, password rotation, workflow approval, and just-in-time (JIT) access, to reduce the risk of insider threats and external attacks that exploit privileged credentials.



Key features of PAM include:

  • Privileged account discovery. Identifying and cataloging privileged accounts and their associated assets.
  • Password management. Ensuring strong and frequently rotated passwords for privileged accounts.
  • Just-in-time access. Granting temporary and controlled access to privileged accounts only when needed.
  • Session monitoring and recording. Capturing and monitoring activities performed by privileged users for audit and forensic purposes.
  • Privilege elevation. Providing a secure and audited way to elevate a user’s access privileges as needed.
  • Least privilege principle. Restricting privileged users to the minimum level of access required to perform their tasks.

PAM vs IAM Summary

IAM focuses on managing access rights for all users across an organization, while PAM specifically deals with securing and controlling privileged access to sensitive systems and data. Both IAM and PAM are essential components of a comprehensive security strategy, working together to minimize security risks and maintain compliance with industry standards and regulations.

About Apono, a Gartner-approved solution

Apono is a granular permission control solution that offers fine-grained access policies to cloud assets. Apono integrates directly with the specific service or resource type. This allows us to  change the permissions at the resource level itself, for example a specific collection or table in your data repository instead of the entire cluster. Our solution allows for control of specific roles and permissions of each resource type and service from one central tool, bringing a unified privilege control plane to the admin, with workflows and audit capabilities on top. 

Just-in-time access permission management

Apono Recognized in 2023 Gartner Magic Quadrant for Privileged Access Management

Apono is excited to announce it’s been recognized in the 2023 Gartner Magic Quadrant for Privileged Access Management! In its short history (founded in 2021), Apono has already received a number of devoted users and is proud to receive this award.

Summary

The significance of robust privileged access management has never been higher, with cyberinsurance firms now insisting on the adoption of PAM tools. Gartner concludes that leaders in security and risk management should leverage the research in the Gartner report to assess the efficacy of their strategies.

What is Privileged Access?

Privileged accounts serve as a significant avenue for breaches to occur.  Privileged access is access beyond the level granted to normal business users. It allows users to override existing access controls, change security configurations, or make changes affecting multiple users or systems. Privileged access can create, modify and delete IT infrastructure, along with company data contained in that infrastructure, so it carries catastrophic risk. 

Managing privileged access is thus a critical security function for every organization. Regular user access controls cannot effectively manage privileged access, so special procedures and tools are required. 

Gartner Defines Privileged Access Management

Gartner defines privileged access management (PAM) as tools that manage and protect accounts, credentials and commands that offer an elevated level of technical access, that is, administer or configure systems and applications. Available as software, SaaS or hardware appliances, PAM tools manage privileged access for people (system administrators and others) and machines (systems or applications). 

PAM solutions secure just-in-time and zero-standing privileged access across hybrid and multi-cloud environments.

Gartner’s four distinct tool categories for PAM tools are the following: 

  • Privileged account and session management (PASM). Vaulting of privileged account credentials, and session management for privileged users
  • Privilege elevation and delegation management (PEDM). Host-based agents that provide command; filtering and privilege elevation for users on macOS, UNIX/Linux and Windows. 
  • Secrets management. Specialized vault focused on managing credentials for software and workloads. 
  • Cloud infrastructure entitlement management (CIEM). Management of entitlements used in cloud service provider (CSP) infrastructure.     

PAM controls ensure authorized use of privileges (including any related mechanism like privileged accounts or credentials) in authorized target systems for all relevant use cases.

Key Capabilities for Consideration

The must-have capabilities for PAM are:

  • Offering centralized management and enforcement of privileged access by controlling either access to privileged accounts and credentials or execution of privileged commands (or both).
  • Managing and brokering privileged access to authorized users (i. E. , system administrators, operators, help desk staff, and so on) on a temporary basis.

Standard capabilities include:

  • Credential vaulting and management for privileged accounts.
  • Agent-based controlled privilege elevation for commands executed on windows, unix/linux or macos operating systems.
  • Privileged account discovery across multiple systems, applications and cloud infrastructure providers.
  • Management, monitoring, recording, and remote access for privileged sessions.
  • Auditing capabilities to ascertain who used what privileged access when and where.

Optional capabilities include:

  • Secrets management for applications and services.
  • Privileged account life cycle management and remote privileged access for vendors, service providers and other external users that require technical access.
  • Just-in-time privilege management to reduce the time and scope that a user is granted a privilege to the minimum possible.
  • Cloud infrastructure entitlement management (CIEM) and discovery.

Apono Enables Simple and Secure Access to Production

With Apono, you can have all the benefits of accessing production data without any of the risks. When an engineer requires access to fix or investigate a production issue, for example, they can get access automatically through the Data Portal, with built-in security policies enabling them to access only the types of data required, and have that access revoked when it’s no longer needed. 

Should Anybody Have Access to Production?

In a perfect world, no one would have access to production, as that’s the safest way to make sure there won’t be any issues, however this remains unattainable for most companies. 

On the one hand, providing developers access to production servers can be risky. If they make changes to the code or configuration, it could break things for everyone else. Also, having too many people with access to production servers can make it more difficult to track what changes have been made and when. 

On the other hand, developers need access to production servers to be able to debug issues that may arise. They also need to be able to deploy code changes and monitor their performance in production. Without any type of access to production servers, many developers would not be able to effectively do their job.

While it’s advisable not to grant access to production environments, often, there is simply no way around it, and access has to be granted. Therefore, you need to ensure that the risks of exposure are as low as possible.

Access to Production

10 Risks of Accessing Production Data

Increasing the number of people who have production access increases the likelihood of the risks typically associated with higher-privileged access. The most common risks are operational impairments due to misconfiguration (e.g., a malformed production change causes the system to become unavailable to its customers), security breaches due to negligent actions, or confidential information leaks due to mishandling datasets. 

  • Accidental Outages. Developers may inadvertently make changes or updates that disrupt production services, leading to downtime or reduced system performance. This can occur due to coding errors, misconfigurations, or incorrect deployment procedures.
  • Data Loss or Corruption. Inexperienced or improperly trained developers may accidentally delete or modify critical data, leading to data loss or data corruption in the production environment.
  • Security Vulnerabilities. Developers accessing production systems may introduce security vulnerabilities, especially if they have excessive or unnecessary privileges. They may inadvertently expose sensitive data or create security holes during development or troubleshooting.
  • Unauthorized Access. Developers with access to production environments could misuse their privileges, intentionally or unintentionally. This misuse might involve unauthorized data access or changes, potentially leading to data breaches or other security incidents.
  • Limited Accountability. In shared or poorly controlled environments, it can be challenging to attribute specific actions to individual developers, making it difficult to identify the source of problems or security breaches.
  • Operational Disruptions. Frequent access by developers can disrupt the operational flow of the production environment. While developers are troubleshooting or testing, the system might be less stable or responsive.
  • Uncontrolled Changes. Developers might make changes in the production environment without adhering to proper change control procedures. This can lead to undocumented changes, making it difficult to track and manage the system effectively.
  • Exposure to Sensitive Data. Developers may encounter sensitive data in production environments, such as personal information or financial data. Mishandling or accidental exposure of this data can result in legal and compliance issues.
  • Resource Constraints. Developers accessing production systems for troubleshooting or experimentation can consume resources and potentially affect the performance of the environment for end users.
  • Lack of Separation of Duties. In some cases, developers may have both development and production access, which can lead to a lack of separation of duties and potential conflicts of interest.

10 Benefits of Accessing Production Data

Allowing developers access to production environments, when done responsibly and with proper controls in place, can bring several benefits to an organization. Here are some of the advantages of letting developers access production environments:

  • Faster Issue Resolution. Developers can troubleshoot and diagnose issues in the production environment more effectively when they have direct access. This can lead to quicker resolutions and reduced downtime.
  • Improved Software Quality. Access to production allows developers to gain firsthand insights into how their code behaves in a real-world environment. They can identify and address issues related to performance, scalability, and compatibility more effectively.
  • Enhanced Collaboration. Developers can collaborate more efficiently with operations and system administrators to optimize the production environment. This cross-functional collaboration can lead to improved system performance and stability.
  • Rapid Deployment and Updates. Developers can deploy new features and updates directly to the production environment, reducing the time between development and deployment. This agility is essential in fast-paced development cycles, such as those in DevOps environments.
  • Effective Monitoring. Developers can set up and configure monitoring tools and alerts in the production environment, enabling proactive issue detection and response. This contributes to higher system availability and reliability.
  • Knowledge Transfer. Developers who are familiar with the production environment can transfer their expertise to other team members, improving overall team capability and reducing reliance on a select few experts.
  • Continuous Improvement. Developers can gather feedback and real-world data from the production environment, enabling continuous improvement of applications and services. This iterative process can lead to better user experiences and business outcomes.    
  • Cost Savings. By empowering developers to handle routine operational tasks and troubleshoot issues, organizations can reduce the need for dedicated operations teams or external support, resulting in cost savings.
  • Agile Development. Developers can perform A/B testing, feature toggling, and other agile development practices more easily in the production environment, facilitating rapid experimentation and feature rollout.
  • Faster Feedback Loops. Developers can receive immediate feedback on their code changes and their impact on the production environment. This tight feedback loop helps identify issues early in the development process.

Giving devs a least-privileged role is how they are typically given access to the production environment. While this is a solid approach, many times developers only need to briefly access a production database system and run a few ad-hoc queries to troubleshoot the current bug. For large organizations, administering access is a full-time job. In an agile world, people move teams and switch to different projects seemingly on an hourly basis. This can lead to a lot of churn in access management to your backend database systems.

A better approach for handling access to database systems would be to allow your application developers to provision their own access and have it revoked with no extra work on your end.  With the right data access controls in place (read-only access), a dev could grant themselves temporary access to certain resources to debug issues that  will be automatically deprovisioned for whenever you choose.

Apono Enables Simple and Secure Access to Production

With Apono, you can have all the benefits of accessing production data without any of the risks. When an engineer requires access to fix or investigate a production issue, for example, they can get access automatically through the Data Portal, with built-in security policies enabling them to access only the types of data required, and have that access revoked when it’s no longer needed. 

Try us Free!

From MFA to Granular Access Controls: Duo, Okta and Apono discuss the new IAM landscape

Policy-as-code

Meet the Speakers

Policy-as-code

Challenges of the Modern IT Environment

In this webinar, we discuss the evolving nature of IT environments, the need for a security culture shift, the challenges and opportunities in modern IT security and the balance between security and user friendliness. 

“Three main changes have occurred in the modern IT environment. The first is that it’s not just an IT department. The modern IT department encapsulates engineering as well because once we’ve shifted to the cloud, we’ve actually shifted the environment and infrastructure to not only belong to what was considered IT but to actually be in the hands of the engineering team, whether they like it or not. Two other pieces: It’s a larger environment, it’s a more complex environment and at the same time, it’s so much easier to make it larger and complex, because today, a click of a button, you can quadruple the size of your environment. The third thing here is stricter regulations we’re seeing in the market today when it comes to managing access.”

 “The modern IT environment is this great engine of next-gen anything—AI everything, and microservices everything. What we’re seeing right now is an inflection point where enough people are starting to do multi-factor. We’ve said for a long time that a lot of attacks would go away if we did multi-factor, and we’ve reached that inflection point and the attackers aren’t stopping. I thought once everyone was running multi-vectory, you should stop, go home, game over we’ve won. But funny enough, the criminals are working around that. We’re starting to see phishing attacks, flood attacks, proxy attacks.” 

“Two biggest challenges are baggage and culture. Baggage is legacy, meaning we build something and tend to leave it alone. If it ain’t broke, don’t fix it, then we just layer things on top of it, so we end up with layers and layers of baggage that we have to deal with and unwind. If you’re looking at zero-trust as one more layer, then you’re looking at it wrong. I think you need to look at zero trust as an opportunity to simplify. It’s also a cultural exploration, too, because it’s a change in the way we think about security.”

 “When everyone started with the Cloud, it really changed things in containers and how we think about permissions to those environments. It’s radically different from how we used to treat a network.” 

Security Versus User Experience 

Access management requires a careful balancing act between access control and productivity. On one hand, privileged access exposes the organization to risks. On the other hand, if we restrict it too much, we end up with bottlenecks resulting in a lack of productivity. 

“Today customers are expecting very fast value, so your teams are required to perform their work quickly with as least friction as possible. I think most companies today are in a lose-lose situation. Most companies today are somewhat over privileged in their environment or maybe a lot over privileged.” 

“For the longest time, we’ve thought about where the user is going. When we think about just-in-time, if you don’t have a good infrastructure component to do it, you’re going to prioritize very rigorously, you’re going to look at your most privileged systems, you’re going to look at your most privileged sensitive data, and you’re going to look at the things that lure in adversaries, but I would argue, just like with any other control, the more easy it is to deploy it, the better the user experience.” 

“We’re in a really neat place when it comes to juxtaposing security with user experience. And we as security people, have always made it harder for users. That’s just what we do. We’ve had password requirements and then we just layer on additional password requirements, which just force users to do unnatural things. We’re at a point now where I think we can provide better user experiences with actually up-leveling that security. Part of that is the workflows around the automation and figuring out which applications are touching which data.”

“I keep hearing that the need for ease of use for users and simplicity is becoming a critical attribute of a security system, and if you’re not starting with that in mind and making sure that whatever control you’re putting in place takes that user experience or administration in mind, then it’s probably not going to scale for this new, modern world, which is very agile.” 

Roadmap to Zero Trust

Zero trust is a concept focused on limiting access to specific resources based on the principle of “never trust, always verify.” It involves dynamically adjusting trust boundaries, adopting a policy-driven approach, and relying on trust signals and telemetry to enforce security.

There’s been a shift away from traditional network-centric security to user and identity-centric security. Zero trust is seen as a way to achieve a more secure and adaptable security posture in today’s diverse and dynamic IT environments. Zero trust is not just a framework but a mindset shift that needs to be integrated into processes and DNA. It’s an ongoing process rather than a one-time implementation.

“I think the network has somewhat shifted into the management of the cloud itself. At some level, it’s now a policy that’s being managed in the cloud, so the network itself is  just another resource. Somewhat similar to how zero trust moves the controls into the resources, now we’re managing these policies across multiple clouds and multiple applications, and that’s actually managing access today . . . Having all the roles very granularly defined is something that’s very hard to accomplish. That’s when you need to build your strategy around what’s most important. What are the crown jewels? Let’s start off from there and then slowly build it rather than trying to achieve zero trust over the whole environment.”

“We shouldn’t be able to do authorization and get our least privileged access (whatever those entitlements and privileges are) all the time. Why should those be standing? If the context and conditions change or if I’m doing something inappropriate, I should be able to revoke that trust. I’m trusting the person to authenticate. I’m trusting the person within my application and that policy enforcement, the idea of I’m going to do just-in-time access or I’m going to do risk-based authentication I think is the critical differentiator between zero trust and what we used to do.”

“This is the natural inevitability of the world we find ourselves in. We’re all clowned, we’re all mobile, we need the same security constructs across everything that we do. I always look at zero trust as a lifestyle choice. It’s a change of behaviors. It’s an evolution of how we think about security and moving security to the edge, moving security to the endpoints that end up being the user on the access device accessing the application where the data lives.”

“Zero trust means we are no longer trusting someone just because they have an IP on the network. We are going to map users to applications, workloads, servers, etc. It’s about starting with user identity and mapping to what they need. Not the network. You don’t give access to the network, you give access to the specific thing you need.”

5 Steps for Moving to the AWS Identity Center

For many organizations using AWS, the challenge of maintaining a least-privilege posture in their cloud operations is becoming increasingly difficult. This difficulty stems from the need to build access systems from scratch, remodel legacy tools, and prepare for future cloud service add-ons. 

In addition, organizations are struggling with creating and managing AWS IAM users and roles, especially when their team grows and needs more accounts. This is why AWS created the AWS Identity Center (formerly known as AWS SSO). It can act as a standalone identity provider for logging into AWS, or it can connect with existing providers, such as Okta and Google.

In this post, we’ll be discussing the methods available for setting up and managing identities in the AWS IAM Identity Center—including the 5 steps everyone must do.

Why Use the AWS IAM Identity Center?

The IAM Identity Center, which follows AWS Single Sign-On, is a cloud service that allows you to grant your users access to the AWS Portal or CLI across multiple AWS accounts. The name change to IAM Identity Center highlights its foundation in IAM while showcasing its extended functionalities and endorsed role. By default, AWS IAM Identity Center now provides a directory that you can use to create users, organize them in groups, and set permissions across those groups. 

Through this platform, it’s possible to manage access to various AWS accounts and applications. This approach is recommended as the primary gateway to AWS, as it empowers you to select your preferred identity source for seamless integration across the AWS ecosystem. Moreover, it enhances your security posture by maintaining consistent permissions across different AWS accounts and applications. 

For smaller organizations who need only one account, AWS IAM is a great choice, but for those big organizations or companies with multiple accounts, moving to the AWS Identity Center is the right choice.

Difficulties Managing Access in Traditional IAM 

  • Time-Consuming. You need to configure each and every user or role inside Amazon. And if there are two accounts, you need to go to the first one, map each role to Okta, then set up the permissions needed for each of them. After that you need to go to the second and repeat the process. For companies with more than 10 accounts, this is a tedious, time-consuming task prone to human errors.
  • Static. The permissions are static, so once they are set, they are not changing. In order to make any permission adjustments for any user or role, you must go inside AWS and manually change the permissions for the specific accounts you want.

5 Steps Needed for Provisioning in the AWS Identity Center 

1. Enabling the IAM Identity Center

When you set up an AWS account, you start with one primary sign-in identity, granting full access to all AWS services and resources within the account.

This identity is known as the AWS account root user and is accessible through the email address and password used during the account creation process. (However, it is strongly advised against using the root user for regular tasks. Instead, it is crucial to safeguard the root user credentials and reserve their use for tasks that specifically demand the root user’s privileges.) To begin, you need to sign in to the AWS Management Console as the account owner by choosing Root user and entering your AWS account email address. On the next page, enter your password.

APONO TIPS

1. It’s important to safeguard your root user credentials. Don’t use the root user for your everyday tasks. Instead use them to perform the tasks that only the root user can perform.

2. Remember, the AWS identity center acts as an SSO portal to all the applications in the organization—not only AWS.

2. Provisioning Users and Groups 

In IAM Identity Center, you have the flexibility to create users and groups directly within the system or utilize existing users and groups from Active Directory or another external identity provider. However, before IAM Identity Center can grant access permissions to users and groups within an AWS account, it needs to be informed of their existence. Likewise, applications enabled by Identity Center can interact with users and groups that are known to IAM Identity Center. Provisioning in IAM Identity Center varies based on the identity source that you use. 

3. Defining Permissions

In order to define the permissions and policies that govern what users have access to within an AWS account, you will need to go into the admin console and configure it all from there unless you use a tool such as Apono.  

APONO TIPS

Keep in mind, with the AWS IAM Identity Center, it’s possible to reuse existing AWS IAM Identity Center policies

4. Assigning Access

In the Identity Center, permissions are administered through sets of permissions, which are essentially groupings of IAM policies. When a user or a group is assigned a permission set associated with an account, the Identity Center will automatically generate corresponding IAM roles within that account. These roles inherit policy configurations from the respective permission set. Furthermore, each role is equipped with a trust policy that ensures the role can only be assumed after the user has been authenticated by the federated identity provider.

5. Removing Access

One of the most important steps, though often neglected, is remembering to remove permissions once they aren’t needed anymore. This helps enforce the zero-principle security  policy that states no one should have standing permissions. 

AWS IAM Users are a crucial aspect of managing access and permissions within the AWS ecosystem. However, relying on long-term credentials can pose tons of risks. Utilizing AWS Organizations, AWS Identity Center, and identity federation can greatly improve the management of users and resources across multiple accounts.

By leveraging these tools and pairing them with permission management applications such as Apono, you can enhance security, streamline administration, and maintain compliance within your AWS infrastructure.

Apono integrates with AWS natively, which allows you to manage access to your S3 buckets, IAM roles and groups, EC2, EKS clusters, RDS instances and many more. 

Some of the benefits of integrating AWS with Apono include the following:

  • Automatic Deprovisioning – Eliminate the need of manually deprovisioning tasks with time-restricted access workflows. 
  • Reduction in Over Privileges – Discover existing privileges to AWS roles, groups and services to convert to on-demand access flows to reduce over-privileges.
  • Self-Service Access – Empower your developers to gain self-servable access to AWS services, buckets, instances and more using Slack.
  • Automated Approval Workflows – Create approval workflows to specific sensitive resources.
  • Restricted Third Party Access – Grant third-party (customer or vendor) time-based access to specific S3 buckets, RDS or EC2 instances with MFA verification.
  • Access Reviews – View a detailed access audit of who was granted access to which specific instances, buckets or other resources in AWS.

To avoid the tedious task of going into the AWS Identity Center admin console every time you need to grant or revoke access, it’s important to use a tool such as Apono. With Apono, users can request and reviewers can grant permissions—without leaving Slack.

Automating On-Demand Access Requests for GCP

When you follow the principle of least privilege, you grant users just enough access so that they can carry out everyday activities, but can do nothing more. Following this principle helps you reduce risk. However, it can create friction for users when they occasionally need to perform a privileged action—such as dealing with an unexpected incident. 

The problem is that most companies are unaware of the solutions available to them—so much so that they are spending manpower slapping together internally made solutions for automating access requests to GCP. In this article, we’ll discuss the three ways you can build JIT access to GCP.

Why Automate On-Demand Access Requests for GCP?

As an admin on a large project, it’s common to be inundated with requests from users asking for access to a project.  This process is filled with inefficiencies – the admin doesn’t really know how to handle these requests, so they forward the request to the project lead, asking for their approval. Once the project lead approves, then the admin has to manually add them to the right group or project role, enabling them access to the project. 

Challenges With Requesting and Delivering Access in GCP

  • Doesn’t know what permissions to give. Things are not necessarily mapped out to the task that the requestor needs to do.
  • Doesn’t know who needs to approve them. For example, if I’m the person giving the permissions, that’s the one managing the GCP here, but maybe I need to go back to their manager to see if he needs one of these. Maybe the security team; maybe the compliance team.
  • Doesn’t know for how long someone needs the permissions. This requires you to go back and forth to ask about the length of time needed.
  • Doesn’t know who currently has permissions to what. There’s a lack of visibility into who has access to what environments or resources     

Solutions

For companies who want to benefit from JIT access to Google Projects, there are three options available. They are the following:

1. DIY

At Apono, we’ve spoken with many companies who, for lack of a better option, built their own internal solutions for requesting access. One such company, Mednition, recently published an article about it. You can find it in whole here. 

The company had a few goals:

  • Fewer standing privileges
  • Faster submitting of tickets for access requests and waiting for approval.
  • Fits within the tech stack currently adopted.
  • Creates an audit trail that’s easy to index and search. 
  • Supports compliance requirements for auditing and logging. 

Here’s the solution the company created:

“We decided to create a Slack bot that runs within GCP Cloud Run and logs the audit trail to GCP Cloud Logging. We will leverage Google Groups for provisioning access and Cloud Identity as the mechanism for managing temporary membership. Cloud Identity will add and remove the user from the group for us, so we don’t have to manage any state (which is amazing to avoid sync issues and edge cases). This is particularly interesting because now we can provide temporary access to third party applications if they can map access to Google Groups (outside of our use case but maybe in the future).” 

On-Demand Access Requests

2. Google’s Open Source Solution

Google’s Just-In-Time Access is an open source application that lets you implement just-in-time privileged access to Google Cloud resources. The application lets administrators, users, and auditors do the following tasks:

  • Administrators can grant a role to a user or group and make the role eligible by adding the following IAM condition: has({}.jitAccessConstraint)
  • Users can search for projects and roles that they’re eligible to access by using the Just-In-Time Access application. (The following screenshot from the Just-In-Time Access application shows a list of roles that a user is eligible for in a project: )


They can then activate one or more roles and provide a justification for getting access:

Screenshot from the Just-In-Time Access application that shows the form for entering a justification.

After a user has activated a role, Just-In-Time Access grants the user temporary access to the project.

  • Auditors can use Cloud Logging to review when and why eligible roles have been activated by users.

To protect the application against unauthorized access, the Just-In-Time Access application can be accessed only over Identity-Aware Proxy (IAP). Using IAP, an administrator can control which users should be allowed to access Just-In-Time Access, and which additional conditions those users must satisfy in order to get access.

3. Out-of-the-box tools

Solutions such as Apono provide plug-and-play authorization workflows so that companies don’t need to start from scratch. Apono serves as the intermediary that connects identities with entitlements, enabling access on a just-in-time, temporary basis. Apono’s privilege authorization capability provides a reliable and streamlined approach to permission management and mitigates the consequences of a GCP permissions-related breach, without compromising user experience and productivity.

On-Demand Access Requests

The image below features an access flow that allows developers to get temporary read-only access to production when needed.

Remember that managing access control effectively is a critical aspect of maintaining the security and integrity of your GCP resources. Regularly review and audit your roles and permissions to ensure they align with your evolving requirements.

New to GCP role management or need a quick refresher?

Here’s a brief overview of everything you need to know. 

The Google Cloud Platform (GCP) provides a robust system for managing access and permissions through roles. Roles in GCP allow you to control what actions users and services can perform within your projects and resources. In this beginner’s guide, I’ll provide an overview of GCP roles and their usage.

1. Understanding GCP IAM: Google Cloud Identity and Access Management (IAM) is the central service that controls access to GCP resources. IAM manages permissions and roles across projects, allowing you to grant and revoke access as needed.

2. Predefined Roles: GCP offers a set of predefined roles with specific permissions. These roles are designed to cover common use cases and provide a level of granular access control. Some of the commonly used predefined roles include:

   – Owner: Has full control over the project, including managing roles and billing.

   – Editor: Can view and modify project resources but cannot manage roles or billing.

   – Viewer: Can view project resources but cannot make any modifications.

   – Billing Account Administrator: Has access to billing information and can manage billing accounts.

   – Compute Instance Admin: Can manage compute instances but not other resources.

   – Storage Object Viewer: Can view objects within Cloud Storage buckets.

   These predefined roles are useful starting points for managing access, but they may not always provide the precise level of control needed for your specific requirements.

3. Custom Roles: GCP allows you to create custom roles tailored to your specific needs. Custom roles offer fine-grained control over permissions by selecting individual actions or setting broad permissions within a particular service. You can define custom roles at the project or organization level and assign them to users or groups as required.

4. Role Hierarchy: Roles in GCP follow a hierarchy where higher-level roles inherit permissions from lower-level roles. For example, the `roles/owner` role inherits all permissions from the `roles/editor` role, which, in turn, inherits permissions from the `roles/viewer` role. Understanding this hierarchy is crucial for managing roles effectively and avoiding unnecessary duplication.

5. Service Accounts: Service accounts are special accounts used by applications, virtual machines, and other services to interact with GCP resources. Similar to user accounts, service accounts can be assigned roles to determine their permissions. It’s important to grant the minimum required permissions to service accounts to reduce the risk of unauthorized access.

6. Granting Roles: Roles can be assigned at various levels, including the project, folder, or organization level. You can grant roles to individual users, groups, or service accounts. It’s recommended to follow the principle of least privilege, granting only the necessary permissions for users to perform their tasks.

7. Testing Access: GCP provides a tool called the IAM & Admin Policy Simulator, which allows you to test the effectiveness of your roles and permissions without making actual changes to access control settings. This tool helps ensure that users have the right level of access without exposing sensitive resources.

Just-in-time Database Access

Just-in-time Database Access

Just-in-time database access is about managing access to specific databases. It has a lot of moving parts and may seem complicated, but there are things that can be done that make it much easier. 

In this blog, we’ll explore roles and how access management to databases works today, why direct access to databases is needed, what an agile approach to access management is, and the ways that just-in-time database access makes the whole process much easier and safer.

All About Roles

In the database world, a role is a group of privileges that can be assigned to one or more users, and a user can have one or more roles assigned to him. 

There are two ways to provision access today. Users have the option to manage identities directly inside the database, or they can connect them to existing identity sources like Active Directory or Okta.

  1. Mapping user identities to roles and permissions. This allows the admin the ability to control access to resources for users already managed in the company’s identity provider. 
  2. Creating new roles.  This means you need to go in and manually create the role you need, then you need to assign that role to each group in the Identity Provider, one-by-one.

Problems with the above

  • Time-consuming. Creating roles in each db and provisioning the right one for each user  takes a lot of manual work and a lot of time.
  • Not adaptable.  Once a set of permissions is attached to a role, then anyone in the group will have the same pre-defined permissions. There is no ability to adjust the permissions per person. This leads to over-privileges because groups are usually granted more permissions than each developer needs just in case they are needed at some point.
  • Unsecure. RBAC doesn’t take credential stealing or losing passwords into consideration even though 80 percent of breaches happen due to lost or stolen passwords.

Why it’s Important to Limit Direct Access in the First Place

Companies strive to limit direct access to databases for many reasons, such as security, as a fail-safe against potential human errors and a number of other benefits. No matter the reason, this type of least-privilege access policy has led to a rise in popularity for BI tools such as BigQuery and Elasticsearch. These tools allow analysts or devs the opportunity to access the data without directly accessing the production environment.

Why Situations Exist When Access Needs to be Direct

Although it’s prudent to follow the zero-trust approach, there are still times when it’s necessary for engineers to enter the production environment immediately, for example, during incidents. Without immediate access to fix things in production, problems can persist and the MTTR rises, resulting in lost time, lost resources and lost money. 

A few examples are the following:

  • Incidents
  • Supporting customers
  • Maintenance and implementations
  • Adding database integrations 
  • Eliminating silos between developers and operations

Just-in-Time Database Access

Provisioning Just-in-Time (JIT) database access enables users to obtain temporary, on-demand privileged access to resources. This approach falls under identity access management or privileged access management and is particularly designed to address scenarios where certain users may not regularly require access to specific applications or services. However, they can gain timely access to these resources when necessary, but only for a limited duration.

Compared to the concept of standing privileges, which grants users constant, broad access to resources, Just-in-Time database access provisioning takes a different approach. It ensures that all access is strictly temporary and granted only to the required resources, what’s called, “Just Enough” access.

Furthermore, this system typically limits access based on roles, aligning with the principle of least privilege (POLP), a requirement in many policies and regulations. The core idea behind Just-in-Time access is to eliminate permanent authorizations or unending access to critical infrastructures, gaining increasing momentum in the security landscape but is also very helpful in maintaining a more stable, yet agile production environment.

By default, Just-in-Time database access makes all access temporary, consistently verifying the validity of users, connections, roles, and privilege levels during every connection establishment. This approach effectively removes implicit trust from the equation, aligning with the fundamental philosophy of the Zero Trust framework – “never trust, always verify.”

The Benefits of Just-in-Time Database Access

  1. Reducing MTTR: By implementing just-in-time database access, organizations can improve incident response times. When access is restricted and granted on-demand, the risk of unauthorized or accidental changes is minimized. This reduces the chances of introducing new issues during the repair process. Additionally, time-restricted access ensures that only qualified individuals can make the necessary repairs, leading to quicker and more efficient incident resolution.
  2. Decreasing Human Error Incidents: Human errors are a common cause of incidents and security breaches. By removing standing privileges and implementing just-in-time access, organizations limit the opportunities for human error to occur in production environments. Access is granted precisely when needed and for specific tasks, reducing the likelihood of unintended changes or mistakes.
  3. Increasing Security: As mentioned earlier, just-in-time access significantly enhances security. By providing temporary and restricted access to resources, the attack surface is reduced. Even if credentials are compromised, the access will be time-limited and tightly controlled, mitigating the potential impact of a breach. This approach aligns with the principle of least privilege, ensuring users only have access to what is necessary for their roles.
  4. Proving Compliance: Compliance with various regulations and industry standards often requires strict control over access to sensitive data and resources. Just-in-time access provides a well-documented and auditable access management system. The ability to generate detailed audit reports that show precisely when and by whom resources were accessed helps organizations demonstrate compliance during audits and regulatory reviews. This process streamlining saves time and resources during compliance assessments.

Overall, just-in-time access is a powerful approach to access management that not only increases security but also supports incident response efforts and regulatory compliance.


About Apono

Apono helps you grant just in time and just enough access to your mission critical and highly sensitive databases while eliminating the need for long-term privileged access. 

Permission Management for Databases

Table of Contents

Part 1: Permission management for databases

Permission management for databases is a sore spot in many DevOps pipelines. 

It requires a careful balancing act between access control and productivity. On one hand, privileged access exposes the organization to risks. On the other hand, if we restrict it too much, we end up with bottlenecks resulting in a lack of productivity. It’s a lose-lose situation. 

It’s Important to Limit Direct Access

Companies strive to limit direct access concerning permission management for databases for many reasons, such as security, as a fail-safe against potential human errors and a number of other benefits. No matter the reason, this type of least-privilege access policy has led to a rise in popularity for BI tools such as BigQuery and Elasticsearch. These tools allow devs the opportunity to access the data without entering the production environment.

However, Situations Exist When Access Needs to be Direct

Although it’s prudent to follow the zero-trust approach, there are still times when it’s necessary for engineers to enter the production environment immediately, for example, during incidents. Without immediate access to fix things in production, problems can persist and the MTTR rises, resulting in lost time, lost resources and lost money. 

A few of examples are the following:

  • Incidents
  • Supporting customers
  • Maintenance and implementations
  • Integrations
  • Eliminating silos between developers and operations

Benefits of Automating Role and Permission Management for Databases

It’s clear there needs to be a solution to the chaos, and there are two approaches to achieve this. They are the following:

  1. One option is to transform it into a makeshift project that requires constant manual maintenance, involving the granting and revoking of permissions every time an individual joins or departs from the company, for example. This would result in a complicated and time-consuming endeavor, where a significant amount of time is wasted setting up permissions for all users. Clearly, this falls short of the ideal solution.
  1. The other option involves employing a flexible and fully automated system for role-based permission management that enables you to maintain a suitable balance between collaboration and control. This approach provides you with peace of mind, knowing that your data is secure and protected.

Problems with Manual Management of Database Permission Management

  1. Lack of Visibility. Apono provides centralized identity visibility so that teams can easily see each identity’s entitlements and permissions across all platforms. With this information, they can make informed decisions about which action to take.
  1. Not Secure. Standing permissions can introduce significant risk if not revoked when they are no longer needed, since they would provide an attacker with access if a user’s credentials are stolen. For organizations seeking to minimize their attack surface, mitigate the risk of data breaches, and ensure compliance, it is crucial to prioritize the reduction of accounts with standing privileges and transition towards a zero standing privilege framework.
  1. Bottlenecks. While we may have succeeded in decreasing complexity and increasing security by removing all access, we inadvertently introduced a bottleneck, restricting the number of individuals who can perform tasks on the database. The absence of self-service capabilities for developers will impede the release process, as it will rely on manual intervention from the database administrator (DBA) to implement necessary changes. This problem gives rise to numerous productivity challenges and effectively halts the CI/CD (Continuous Integration/Continuous Deployment) process whenever database-related tasks are involved.
  1. Static. Different situations call for different solutions, and permission management is no different. With dynamic authorization, you specify the authorization conditions and behaviors that govern each of your resources, including data stores, APIs, and applications. Conventional role-based access control (RBAC) lacks precision in the authorization process, while dynamic authorization offers a more intricate authorization service. Instead of relying on fixed permissions and role assignments to safeguard your resources, you can now configure policies that consider a wide range of attributes. By incorporating external attribute data, you can make highly detailed authorization decisions, placing a greater emphasis on context in the decision-making process. This context is evaluated for every resource request, enabling a tailored approach to authorization management that surpasses the coarse-grained nature of traditional authorization.

Benefits of Automated JIT Access to Databases

Just-in-Time access grants users just in time and just enough access to mission critical and sensitive databases. It eliminates the need for long-term privileged access for users and reduces the attack surface.

  1. Centralized Visibility. Database permissions are usually messy. We have zero visibility and too many passwords and permissions, making it difficult to know who has permissions to what. Having a centralized depository that automatically documents and manages user permissions is essential for post-mortem analysis.
  1. Time-restricted access. Automating the revoking of permissions after a specified time period assures there are no standing permissions that could be abused. 
  1. Tool Adoption. Company-wide tool adoption is just as important as what the tool does. If it’s not user-friendly, there will be friction. It’s important the tool fits in smoothly with the rest of the tool stack.

It is evident that when it comes to permission management for databases, we must establish order amidst chaos, and luckily there are ways to create a win-win permission management situation when it comes to provisioning database access.