Learn more about common use cases with Apono for DevOps and DevSecOps professionals:

1. Ensuring SLA (service level agreements)

2. Protecting PII (Personal Identifiable Information) and customer data

3. Maintaining production stability and reliability

4. Break Glass Protocol

Ensuring SLA

An SLA is a legally binding contract between a service provider and a customer. SLAs ensure both parties clearly understand service quality expectations and the repercussions of not meeting the agreed-upon standards.

The service provider and the customer negotiate and agree upon SLAs, typically before the service commences. This is necessary to create a clear understanding of the performance and reliability expectations for the service and to safeguard the interests of both parties.

If your company is a technology vendor, providing SaaS or other services and products to customers, SLA are your business.

This means you are required to ensure performance and reliability, prevent downtime and fix issues within set timeframes. Usually, these timeframes range from immediate, in the case of urgent issues, to several hours or days.

To achieve this, most companies have on-call, incident response protocols and tools, where some developers or teams work in alternating shifts to fix production issues when they arise. How do you make sure customer SLA are met, while also keeping least privilege and preventing standing access to the most sensitive environments and resources?

Apono is here to help.

How to ensure SLA Agreements are met

Apono break glass protocols

Committed to fixing production incidents 24/7? Apono helps users create Access Flows that enable break glass protocols. This is especially handy off-hours (at night and during weekends and holidays, when approvers might not be available).

1. Enable automatic access upon request to on-call shifts and developers on-duty

2. Create bundles that represent customer environments, tenants, databases and other resources to grant to developers in case of emergency

   1. Developers can request a bundle which grants them the exact access they need to investigate and solve the issue

3. Use our webhooks solution to trigger Access Flows automatically when an incident is created in your incident response tool

Access management to customer data

Apono helps you drive sales and keep customers satisfied by ensuring least privilege to customer environments and databases. This can also help prevent mistakes in customer environments, like changes to production environments, human error and confusion between tenants and mistakes, like change or deletion of data.

1. Create Access Flows around CRUD actions to customer environments and databases.

2. Make sure developers and Customer Success representatives gain such access only in case of incident that requires their attention or upon approval.

Production stability

SLA is often about how quickly your R&D team can fix production issues, but a big part of SLA is reliability.

DevOps and SRE professionals can reduce downtime risk with Apono by putting guardrails around production environments and resources.

1. Create Access Flows around CRUD actions on production environments and resources, like code repositories, instances, servers, and more. Apono provides fine-grained access management so that you can control access granularly.

2. Make sure developers gain such access only in case of incident that requires their attention or upon approval.

3. Help your developers prevent human errors. Apono access requests and access details separate different environments and prevent confusion; developers can only request the access permitted to them by Access Flows and the access request process zooms them in to the right resource or bundle for their tasks.

Intro

PII protection is crucial. The two most common use cases for PII protection are:

1. Your company needs to comply with HIIPA, SOC 2, PCI DSS, GDPR or other compliance standards and regulations that require safeguarding Personal Identifiable Information.

2. To enable sales and client satisfaction, you need to put guardrails around customer data; they want to know access is highly restricted to their tenant and their data.

Apono is here help!

How to protect PII with Apono

Apono specializes in protecting data. With Access Flows, you can control exactly who can access DBs with any permission (read, write, create, delete, duplicate, admin, and more):

1. We support all common databases and keep adding more:

2. We help you manage access with full granularity and flexibility:

How it works

1. Integrate Apono with your data repository

2. Apono will auto-discover clusters, databases, collections and schemas

3. Create an Access Flow for the resource type you want to control

4. Fully auditable with logs and reports out-of-the-box

How to secure customer data with Apono

Database access control is key to customer satisfaction - customers want to (and are required to) ensure least privilege to their data and their customers' data by their vendors.

This may include metadata, like users, resource names (like DBs, repositories, etc.), DaaS (data as a service) titles and paths, and also actual data, especially Personal Identifiable Information of customers and employees (names, IDs, addresses, emails, phone numbers, and any other personal attribute).

Apono handles the access workflow for each user who needs to access a customer environment, account, tenant or database, including approval, provisioning, secure access details, revocation and audit:

How it works

1. Put your customers at ease with Apono's documentation and architecture. Contact us and we'll provide out-of-the-box, white-labeled documentation!

2. Integrate Apono with your data repository

3. Apono will auto-discover clusters, databases, collections and schemas

4. Create an Access Flow for the resource type you want to control. Limit access using:

   1. Tags for customers' resources

   2. Specific environments or tenants

   3. Specific customer databases

5. Users will be able to request access to perform any action (READ, WRITE, DELETE, ADMIN, etc.) on customer data

Intro

Break Glass Protocol or Procedure: Granting Emergency Access to Critical Systems. Break glass (which draws its name from breaking the glass to pull a fire alarm) refers to a quick means for a person who does not have access privileges to certain information to gain access when necessary.

In case of emergency, like a production incident or downtime, we want to have quick ways to give respondents elevated, admin access to investigate and fix the issue.

Usually, break glass protocol applies to highly sensitive environments or resources or to very powerful permissions, which is why you want good protections and workflows around it.

If you're working with PagerDuty, OpsGenie, VictorOps, Jira or any other incident response/on-call tool, this is for you.

How to create a break glass protocol

With Apono, you can easily create "break glass" Access Flows that would enable developers-on-duty to and incident responders to mitigate issues quickly, and without compromising on security.

1. Integrate Apono with your on-call/incident response tool to continuously sync Shift members:

1. Create Bundles for your sensitive environments and resources.

• These can be cloud environments, databases, servers, machines, apps, pods, and more.

• Bundles can represent a job to be done, an environment or app to fix, a customer tenant, or any other scope that helps on-call developers access what they need in an emergency.

• Change to your environment or stack? Add anything to your bundle and it will affect all break glass Access Flows. Read more about dynamic access management here.

1. Set the Break Glass protocols:

   1. Create an Access Flow

   2. Insert the relevant bundle

   3. Set the requester as the on-call shift

   4. Set the approver to automatic

2. Developers-on-duty can now request access quickly in Slack, Teams or CLI

Automatic access grant triggered by incidents

Want developers on duty to gain access even faster?

Audit and Security

Even during crisis, you don't want to compromise on your compliance and security.

That's why with Apono:

1. All Access Requests are logged and audited, including automatic access.

2. Every Access Request can trigger a ticket to be created in your ITSM.

3. Admins and developers-on-duty can revoke access at any time.

4. You can set the access time from minutes to hours, so that access is short-lived.

5. Even during on-call incidents, you can still require approval by groups, shifts, managers or individuals.

Intro

Downtime is one of the scariest words in product development. When customers and users trust your product, they expect performance, quality and availability, often governed by Service Level Agreements (SLA).

Apono helps admins and resource owners control access to their production assets with dynamic Access Flows.

• Just-in-Time access requests keep your production environments least-privilege, which prevents human errors and sabotage.

• When needed (for everyday work or during incidents), developers can be granted temporary access.

• Access requests help prevent errors and confusion with pre-defined bundles for incidents and tasks.

How to improve production stability with Apono

Access bundles for tasks or incidents in production

With Apono, users can request bundles set for different tasks and incidents by admins or create freeform access requests based on their Access Flows. The process prevents users logging in to the wrong environment or tenant and performing changes.

1. Integrate your cloud environments with Apono

2. Integrate other crucial production systems, like CI/CD tools, databases and you incident response tool

3. Create an access bundle containing exactly the right resources and permissions for different incidents, production environments, customers and teams.

4. When needed, developers can use Slack, Teams or CLI to request that bundle temporarily

This process limits the access users can request and helps them focus; when there's an urgent production incident, developers can request all the access with a single click.

Least privilege and access control in production

Keeping production environments least privilege in the first place reduces risk of downtime; the less users can perform CRUD actions on your sensitive assets, the last issues and errors you'll run into.

With Apono, you can:

1. Integrate your cloud environments and other crucial production systems, like CI/CD tools databases with Apono

2. Use tags to label your most sensitive instances and resources

3. Create Access Flows around production instances and resources with differing flows;

   1. Read access can be granted temporarily and automatically

   2. Write access can be granted temporarily with approval

   3. Delete and Admin access can be granted temporarily with several approvers

4. Approvers can be a developers' team lead, the resource owner, your DevOps, DevSecOps, Infra or other team, as well as shift members. Apono also lets you require several approvers for extra-sensitive actions and resources.

5. When needed, developers can use Slack, Teams or CLI to request access to production

Separation of environments and tenants

As your product and company grow, more and more environments, tenants and accounts are created. Each developer has several local and staging/development/playground environments at any given moment, on top of different environments or tenants for customers.

This naturally causes confusion and, unfortunately, human errors in production. Developers are accessing the wrong environment, deploying code to production by accident and moving, changing or even deleting databases.

Apono helps prevent unnecessary production incidents:

1. Admins separate environments with bundles and Access Flows, making their management easier

2. Admins control what resources are requestable for different users, so that users can only request access relevant to them

3. Users create access requests and pick bundles or resources they need access to. When approved, access details are sent with the link to the exact instance, preventing confusion

4. If you decide to require approvers, another user will examine the request to make sure the resources and permissions make sense for that user.