Meet the Speakers

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. 

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. 

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.

Try us free today!

Get started

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.

Try us free today!

Get started!

You know the frustration when you check your bank balance, and there’s another $40 charge for the gym membership you forgot to cancel. Or, more likely, you didn’t cancel it ‘just in case’ you wanted to work up a sweat sometime. 

Always-on privileged access (otherwise called ‘standing privileges’) manifests similarly. 

77% of organizations grant unrestricted access to employees who don’t need it, but an always-on approach doesn’t necessarily help them do their jobs. Instead, it provides opportunities for security breaches that could easily fly under the radar. 

In 2022 alone, 55% of organizations suffered a cyber attack where hackers phished privileged credentials, which Verizon flagged as a critical attack vector.

This article will review why just-in-time (JIT) permission management provides the security and speed organizations need to control access. We’ll also look at the types of JIT management, what automated JIT is, and the best practices for enabling it in your business. 

What is Just-In-Time permission management?

Just -in-time permission management or JIT (aka. Just-in-time access) is a cybersecurity practice that follows the principle of least privilege to grant users access to assets only when they need it for a limited timeframe. When time’s up, users lose access to resources such as applications and systems. 

Using the JIT methodology to limit the window of time a user has access rights also limits attackers’ chances to infiltrate your cloud security perimeter.  

45% of breaches in 2022 were cloud-based in light of the increasing number of applications, services, users, and resources in the cloud, making just-in-time permission management (JIT) a must-have. While traditional PAM processes (e.g., session management) succeed as a network-based access solution for on-premises environments, JIT is ideal for controlling access across cloud resources. 

Types of Just-In-Time permission management 

• Ephemeral – A one-time account is created to fulfill the user’s access requirements and then disabled or deleted. 
• Temporary – Users request elevated privileges on their existing accounts when needed. 
• Justification-based – Users must justify why they require privileged access according to predetermined policies. Then, a privileged account and credentials are created and rotated using a central vault.  It’s also called ‘broker and remove’ access. 

What is automated Just-in-Time permission management, and why do you need it?

Assigning JIT permissions manually is like playing a game of whack-a-mole – requests pop up all the time across your organization, and you have to respond at lightning speed to avoid disgruntled colleagues. 

59% of organizations fail to deploy zero trust due to resource constraints, so can you realistically dedicate time and personnel to granting and revoking access all day?

In contrast, automated JIT platforms help relieve friction caused by manual permission management by validating, monitoring, and revoking access without human intervention. Automated JIT platforms have features like auto-expiring permissions and reporting capabilities, enabling users to self-serve permission requests without compromising your organization’s security posture. Putting permission management in the hands of an automated JIT platform prevents human error to minimize the attack surface, eliminates bottlenecks, and ultimately helps maintain productivity.

What are the benefits of automated Just in Time permission management

As well as taking a weight off your IT and security teams’ shoulders, automated JIT has many other benefits. 

Enhances security posture

According to IBM’s Cost of a Data Breach report, compromised or stolen credentials were the most common attack vector in 2022. Automated JIT drastically reduces the risk of privilege abuse and breached identities by eliminating the need for standing privileges. 

Boosts business productivity 

Say goodbye to manual review cycles, wait times, and human error with an automated JIT approval workflow. You can grant access at scale to suit each task at hand, which would make a massive dent in your operational efficiency without automated JIT. 

Improves compliance 

With automated JIT, you can satisfy compliance and customer requirements like SOC2 by enforcing zero trust, least privilege access, and auditing all privileged access activities. Automated JIT platforms can include auditing and reporting features to help you gain visibility over all sessions and privileges. 

How can you enable Just in Time access?

Here are seven best practices you can follow when enabling and implementing JIT access. 

1. Identify and inventorize

First, it’s time to take stock. Begin by identifying the accounts and assets with the most privileges that pose the highest risk, usually those belonging to administrators. You can implement JIT access control to these accounts first, then work your way down the chain. 

2. Use RBAC and ABAC

You can use role-based access control (RBAC) and attribute-based access control (ABAC) as supplementary solutions to define granular policies and circumstances for elevated access. RBAC and ABAC can help you categorize accounts and differentiate the rights they need, then create a control policy that users must meet to receive access. 

3. Define and enable temporary access

As well as defining policies for justification-based access, you can create criteria for users that request temporary access, such as which accounts are valid and the duration of access. You can also implement time-based controls. For example, granting access to specific resources during pre-defined days and times. 

4. Record and audit activity 

An automated access management solution provides visibility over your operations by logging all access activities and enabling alerts responding to dodgy behavior. You can also record and log JIT privileged access. A (digital) paper trail is essential for auditing, governance, and compliance with regulations like SOC2 and PCI-DSS. 

5. Assign responsibility 

You’ll need to delegate responsibilities to employees and decide who will review permission requests. Training employees on how and when to grant or revoke access is essential to minimize incident risk, especially in moments like ‘break glass’ and ‘on-call’. This is where automated JIT comes in handy. It helps you configure ‘break glass’ and ‘on-call’ access flows to resolve incidents and remove bottlenecks like waking DevOps staff. 

6. Use short-lived (ephemeral) credentials 

You should manually rotate credentials regularly to invalidate them, so hackers cannot use a password even if they get their hands on it. You can do this in a centralized vault that, of course, requires the highest security clearance possible. 

7. Use an automated access management tool

The best way to simplify cloud access management is to use a solution like Apono that enforces an automated JIT approach. You can minimize friction, remove over-privileges, and prevent permissions from slipping through the cracks by using Apono to suggest automated JIT access. Standing privileges will never put your organization at risk again. 

Automate Just-In-Time Access and Secure Cloud Assets with Apono

40% of IT and security professionals say that cloud security is their top priority in 2023. 38% point specifically to identity and access management, and 25% say zero trust, signaling the final nail in the coffin for standing privileges. JIT access provides an effective solution for organizations of all sizes to improve their security posture and remain continuously compliant without impeding productivity. 

With Apono’s cloud-native permission management platform, you can automate permission granting for your entire stack based on organizational context and approval workflows. So you don’t need to spend time manually provisioning access. Apono integrates seamlessly with your cloud environments for a smooth user experience and streamlines compliance and customer requirements. 

Try us free today!

Get started

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).” 

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: )

• 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.

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.

Try us free today!

Get started

---

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 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. 

Try us free today!

Get started

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.

2. 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.

2. 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.

3. 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.

4. 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.

2. Time-restricted access. Automating the revoking of permissions after a specified time period assures there are no standing permissions that could be abused. 

3. 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.

Try us free today!

Get started

At Apono, we constantly hear from customers how difficult it is to set up granular permissions with F5, so we decided to dive in and see what’s so frustrating. We found a total of 6 issues. Check them out below.

Quick Overview: What is F5?

F5 is a company specializing in application security, multi-cloud management, online fraud prevention, application delivery networking (ADN), application availability & performance, network security, and access and authorization. 

Challenges of F5 Permission Management

• Not flexible
  • Distributed workforces, rapid cloud adoption and a reliance on connected systems means that today sensitive data is copied, moved and shared to systems and collaboration tools that reside outside of the business. 

• No internal auditing processes.
  • Legacy data permission practices and technology make it impossible to audit data permissions based on a business’s sensitive information and where it lives. As a result, system administrators struggle to stay on top of data access.

• No way to generate temporary permissions on-demand.
  • Permissions are static, so any change needs to be done manually, which takes time and manpower.

• Too many over-privileges 
  • For many companies, the quickest and simplest way to give out permissions is to just  assign a person the highest and widest access policies. 

• Requires manual oversight to maintain.
  • Manual provisioning and de-provisioning of access is labor-intensive and prone to human error or oversight. It is not an efficient or sustainable way to manage user identities and access, especially for large enterprises.

• Customer data not secure.
  • With the proliferation of over-privileged credentials, it’s easier than ever for attackers to gain access to secure information, which is why it’s important that permissions be temporary and limited in scope. 

• Proxy-based.
  • F5 has a roof that allows you to set a workflow such as “this IP can access this IP,” which is too broad for granular-level access policies. 

Luckily, there are ways to overcome these obstacles. Read on below to find out how.

How Apono Makes F5 Permission Management Work

1. Just-in-Time (JiT) Access. “Always-on” privileged accounts have long reigned as the default mode for administrative access. Today, these powerful, always-on accounts proliferate across enterprises. This means that the privileged access, rights, and permissions are always in an active mode and ready to be exercised—for legitimate activities as well as for illicit ones.

2. Automated Access Workflows. Setting up automatic workflows saves manual labor and time. They also allow for break-glass scenarios when needed, which decreases MTTR and downtime.

3. Self-Serve Permissions. Self-service access workflows allow you to create a process for your users to request access to datasets quickly and easily.

4. Resource-based access policies. Apono allows you to grant permissions to granular-level resources such as down to specific namespaces.

“Apono allows us to generate temporary permissions upon request on a very granular set of restrictions, delivering huge value to the business by reducing that Excel phase and optimizing the day-to-day work of multiple teams, including the R&D operations and security teams.”

As you can see, creating on-demand, granular-level permission access policies is impossible to do with just F5 alone. In order to benefit from JIT with F5, it’s imperative that you use a tool that can handle dynamic context. In other words, F5 permission management doesn’t have to suck anymore.

Try us free today!

Get started

Introduction to Permissions in MySQL

MySQL is a database application for Linux and part of the popular LAMP stack (Linux, Apache, MySQL, PHP). A MySQL installation includes options of managing through a root user or specific user accounts.

Managing user credentials in MySQL can be a time-consuming task, particularly when dealing with numerous MySQL instances spread across multiple servers. 

In this article, we’ll be reviewing how to do the following: 

• How to create users in MySQL
• How to grant user permissions in MySQL
• How to revoke user permissions in MySQL

MySQL Databases and Users

Once you have MySQL installed on the server(s) that will host your MySQL environment, you need to create a database and additional user accounts. In order to run the following commands, log into the MySQL instance with the MySQL root account.

Create MySQL databases 

Creating a MySQL database involves a few simple steps. Here’s a step-by-step guide to creating a new MySQL database:

1. Create a New Database:

Now that you are connected to MySQL, you can create a new database using SQL commands. In the MySQL command-line client or phpMyAdmin, use the following SQL statement to create a new database (replace “Apono_database” with the desired name of your database):

  CREATE DATABASE Apono_database;

2. Verify the Database Creation:

To ensure that the database was created successfully, you can check the list of databases. In the MySQL command-line client, use the following command:

  SHOW DATABASES;

3. Use the New Database (Optional):

If you want to work with the newly created database, you need to switch to it using the following command in the MySQL command-line client:

  USE Apono_database;

That’s it! You have now successfully created a MySQL database. You can start creating tables and inserting data into it to build your application or manage your data. Remember to handle database credentials and access permissions with care to maintain security.

Create MySQL users

Creating a MySQL database involves a few simple steps. Here’s a step-by-step guide to creating a new MySQL database:

1. Install MySQL:

If you don’t have MySQL installed on your system, you need to install it first. You can download the MySQL Community Server from the official MySQL website: https://dev.mysql.com/downloads/

2. Start the MySQL Server:

Once you have MySQL installed, start the MySQL server. The process for starting the server varies depending on your operating system. On most systems, you can start the server using a command or by starting the MySQL service.

3. Connect to MySQL:

After the server is running, you need to connect to it using the MySQL command-line client or a graphical tool like phpMyAdmin.

– For the command-line client, open a terminal or command prompt and type:

  mysql -u root -p

  You will be prompted to enter the MySQL root password.

– For a graphical tool like phpMyAdmin, open a web browser and navigate to the phpMyAdmin URL. You can log in using your MySQL root credentials.

4. Create a New Database:

Now that you are connected to MySQL, you can create a new database using SQL commands. In the MySQL command-line client or phpMyAdmin, use the following SQL statement to create a new database (replace “Apono_database” with the desired name of your database):

  CREATE DATABASE Apono_database;

5. Verify the Database Creation:

To ensure that the database was created successfully, you can check the list of databases. In the MySQL command-line client, use the following command:

  SHOW DATABASES;

6. Use the New Database (Optional):

If you want to work with the newly created database, you need to switch to it using the following command in the MySQL command-line client:

  USE Apono_database;

That’s it! You have now successfully created a MySQL database. You can start creating tables and inserting data into it to build your application or manage your data. Remember to handle database credentials and access permissions with care to maintain security.

How to Grant Permissions in MySQL

To grant permissions in MySQL, you’ll need to have administrative privileges or the GRANT OPTION privilege on the database you want to modify. Here are the steps to grant permissions to a user in MySQL:

1. Connect to MySQL: Open a terminal or command prompt and connect to MySQL using a user account with administrative privileges. For example:

   mysql -u root -p

   You will be prompted to enter the password for the ‘root’ user or the administrative user you provided.

2. Select the database: If you want to grant permissions for a specific database, first select it using the following command:

   USE Apono_database;

3. Grant the permissions: Now, you can grant various privileges to the user using the `GRANT` statement. The basic syntax is as follows:

   GRANT privilege_type ON database_name.table_name TO 'user'@'host';

   Replace `privilege_type` with the specific privileges you want to grant. Here are some common privileges:

   – `SELECT`: Allows the user to read (SELECT) data from tables.

   – `INSERT`: Allows the user to insert new rows into tables.

   – `UPDATE`: Allows the user to modify existing rows in tables.

   – `DELETE`: Allows the user to remove rows from tables.

   – `CREATE`: Allows the user to create new tables or databases.

   – `DROP`: Allows the user to delete tables or databases.

   – `ALL PRIVILEGES`: Grants all privileges on the specified objects.

   Replace `database_name.table_name` with the specific database and table (or `*` for all tables) where you want to grant the privileges.

   Replace `’user’@’host’` with the username and the host from which the user will connect. For example, `’john’@’localhost’` refers to the user ‘john’ connecting from the same machine as the MySQL server.

   For example, to grant SELECT, INSERT, UPDATE, and DELETE privileges on all tables of a database called ‘exampledb’ to a user ‘exampleuser’ connecting from ‘localhost’, you would use the following command:

   GRANT SELECT, INSERT, UPDATE, DELETE ON exampledb.* TO 'exampleuser'@'localhost';

4. Apply the changes: After executing the `GRANT` statement, you need to apply the changes for them to take effect:

   FLUSH PRIVILEGES;

5. Exit MySQL: When you’re done granting permissions, exit the MySQL command line interface by typing:

   EXIT;

The user ‘exampleuser’ should now have the specified privileges on the ‘exampledb’ database or the specified tables within it. Make sure to grant the appropriate permissions based on your application’s requirements to ensure security and access control.

How to Revoke Permissions in MySQL

To revoke permissions in MySQL, you can use the `REVOKE` statement. This allows you to remove specific privileges from a user or role. Here’s how you can do it:

1. Connect to MySQL: Open a terminal or command prompt and connect to MySQL using a user account with administrative privileges. For example:

   mysql -u root -p

   You will be prompted to enter the password for the ‘root’ user or the administrative user you provided.

2. Select the database: If you want to revoke permissions for a specific database, first select it using the following command:

   USE Apono_database;

3. Revoke the permissions: Now, you can revoke specific privileges from the user using the `REVOKE` statement. The basic syntax is as follows:

   REVOKE privilege_type ON database_name.table_name FROM 'user'@'host';

   Replace `privilege_type` with the specific privileges you want to revoke. These should match the privileges you previously granted to the user. For example, if you previously granted SELECT, INSERT, UPDATE, and DELETE privileges, you would use the same list of privileges in the `REVOKE` statement.

   Replace `database_name.table_name` with the specific database and table (or `*` for all tables) from which you want to revoke the privileges.

   Replace `’user’@’host’` with the username and the host from which the user was connecting. For example, `’john’@’localhost’` refers to the user ‘john’ connecting from the same machine as the MySQL server.

   For example, to revoke SELECT, INSERT, UPDATE, and DELETE privileges on all tables of a database called ‘exampledb’ from a user ‘exampleuser’ connecting from ‘localhost’, you would use the following command:

   REVOKE SELECT, INSERT, UPDATE, DELETE ON exampledb.* FROM 'exampleuser'@'localhost';

4. Apply the changes: After executing the `REVOKE` statement, you need to apply the changes for them to take effect:

   FLUSH PRIVILEGES;

5. Exit MySQL: When you’re done revoking permissions, exit the MySQL command line interface by typing:

   EXIT;

That’s it! The user ‘exampleuser’ should no longer have the specified privileges on the ‘exampledb’ database or the specified tables within it. Make sure to carefully revoke only the permissions that are no longer necessary, to maintain proper access control and security.

Conclusion

You should now be able to create, modify, delete users and grant permissions in a MySQL database.

Remember, to improve security and limit accidental damage it’s important to limit users only to the privileges required for their jobs.

Check out our article about Just-in-Time Access to Databases. 

Try us free today!

Get started

When enabling MongoDB Authentication post-set up, it’s important to do the following things if you want to avoid downtime.

Introduction: Productivity versus Security

Organizations must strike a balance between enabling employees to be productive and efficient while ensuring that access to sensitive information and resources is adequately protected. 

On one hand, productivity is crucial for organizations to remain competitive and achieve their goals. Employees need access to various systems, data, and tools to perform their tasks efficiently. Restricting access too much or implementing overly stringent security measures can hinder productivity and impede workflow.  

On the other hand, permission security is necessary to safeguard sensitive information, prevent unauthorized access, and mitigate the risk of data breaches or other security incidents. Organizations need to implement access controls, user permissions, and authentication mechanisms to ensure that only authorized individuals can access specific resources. These security measures help protect confidential data, intellectual property, and other critical assets from unauthorized use or disclosure.

Finding the right balance between productivity and permission security involves careful consideration and risk assessment.

Background: DB Access That is Not Authorized or Authenticated

When using a VPN or VPC, it’s easy to think that you don’t need any authentication or ways to enable authorization. After all, it is a private network. And, when it comes to productivity, manual provisioning takes time and needs constant oversight. It’s easy to see why so many companies choose to forgo security in favor of productivity. 

However, as these companies grow, they need to implement security measures and be compliant–all without interrupting productivity.

“Companies want to restrict access; they don’t want everyone to have access without a user password. Rather, companies want to make sure that people have different levels of access without hurting the R&D productivity.”

– Rom Carmel,
CEO and Founder, Apono

Method for Access Control: Adding User Passwords Post Set-up

For the many companies that didn’t set up authorization in MongoDB at the very beginning, it’s not too late. Setting it up after transitioning to the cloud is not impossible, but it does take some know-how. 

• Identifying Your Users
  • To be able to identify who the user is, you first need the connection string to get the username and password for your database user. If there is none, you can create a new database user to obtain these credentials. 

• Enabling Authorization in MongoDB
  • MongoDB does not enable access control by default. DBAs can enable authorization using the –auth or security.authorization setting. When you enable authentication, this also automatically enables client authorization. Enabling access control on a MongoDB deployment enforces authentication. With access control enabled, users and applications are required to identify themselves and can only perform actions that adhere to the permissions granted by the roles assigned to their user.

• Enabling MongoDB Authentication
  • Enabling authentication in MongoDB is necessary for user passwords to be recognized and read. But once you enable it, you’re breaking the way that everything works today, such as accessing MongoDB without a username or password.

Problem: MongoDB Authentication Breaking the Way Everything Works.

It’s not only people who need to access MongoDB to be affected; it’s also applications. So, in effect, none of the applications can access that MongoDB either.

Enabling authorization post-set up will break how teams work unless it’s done smartly.

How We Solved the Transition to MongoDB Authentication

It’s important to run the mongoDB with TransitiontoAuth enabled, which allows for accepting of  both authenticated and unauthenticated connections. Clients connected to the mongoDB during the transition state can perform read, write, and administrative operations on any database, so it’s important to remember to disable the feature after transitioning. 

This transition puts the company in an in-between state that allows access two ways: ones with user password connection strings and ones without. So, essentially you’re not really restricting any access because you can access it also without the user password. However, you are now starting to log and can therefore see who  hasn’t moved to using a password yet.

“You don’t want to just disable it before you’ve seen that all the people and applications who use and access that MongoDB have shifted to moving to working the new way.”

Rom Carmel

Conclusion: When in transit mode you should start working with Apono

Without Apono, it’s necessary for companies to create their own users and their own policies to these. But with Apono, they don’t need to do that. They can ask for what they need, and it’s automatically granted. How? When someone asks permission for a user, Apono goes inside the Mongo, creating a policy that will fit those needs, and giving the requestor a user. Then that user can be utilized to connect the model when the authentication is turned off. 

Try us free today!

Get started

Our team had an amazing time at Kubecon Amsterdam, connecting with DevOps and developers from around the world and showcasing our permissions management automation platform—Apono. 

We were thrilled to see the excitement and interest in our solution, as attendees recognized the need for better permission management in their organizations—from a security, time-saving and compliant perspective.

In addition to showcasing Apono at the conference, we also held several technical sessions to help attendees learn how to automate permission management. These sessions covered a range of topics, from gaining access visibility in K8s clusters to creating incident response access flows for on-call groups.

A few take-ways from our team at Kubecon:

Overall, Kubecon Amsterdam was a fantastic opportunity to meet like-minded individuals who share our passion for innovation for k8s in the cloud-native space. 

We look forward to continuing to develop solutions that help organizations better manage their cloud environments and improve their security posture.

Try us free today!

Get started