How Database Access Controls Evolved to Meet Modern Security Needs

Teleport's Database Access Controls (DAC) have always been designed to offer secure, auditable access to databases. But in today's rapidly evolving security landscape, simply having access controls isn't enough. Organizations need more granular control, better visibility, and seamless integration with existing security policies. This post explores how Teleport's latest features—object-level permissions and Teleport Policy integration—address these needs.

The Challenge: Balancing Security and Usability

Imagine you're managing access to critical databases across multiple environments. On one hand, you need to ensure that access is tightly controlled and auditable. On the other hand, you don't want to slow down developers with cumbersome processes. This balance is difficult to achieve with traditional database access methods, which often involve shared accounts, manual provisioning, and a lack of granular control.

Teleport's Database Access Controls (DAC) have evolved to solve these challenges, providing a secure, scalable solution that enhances both security and usability. Let's dive into the latest updates and see how they can transform your database access strategy.

Role-Based Access Control: A Primer

Consider Bob, a developer who needs access to databases in the dev and staging environments. With a simple developer role, Bob can log into any database in these environments using either viewer or editor roles.

kind: role
version: v7
metadata:
  name: developer
spec:
  allow:
    db_labels:
      environment: ["dev", "stage"]
    db_users: ["viewer", "editor"]
    db_names: ["main", "metrics", "postgres"]

This setup gives Bob easy access while ensuring that his connection is secure and auditable. Teleport uses cryptographically secure certificates for authentication, eliminating the risk of shared secrets being stolen or reused. The session is tied to Bob and will automatically expire after a set time, adding another layer of security.

But what if you need even more control? What if you want to ensure that each user has their own database account, with permissions tailored to their role? That's where our latest updates come in.

Automating User Provisioning for Enhanced Security

Traditionally, creating and managing individual database accounts has been a manual, time-consuming process. This often leads to delays in provisioning and accounts lingering longer than necessary, creating security risks.

With Teleport's automated user provisioning, you can eliminate these problems. Here's how the developer role looks with this feature enabled:

kind: role
version: v7
metadata:
  name: developer
spec:
  allow:
    db_labels:
      environment: ["dev", "stage"]
    db_names: ["main", "metrics", "postgres"]
    db_roles: ["viewer", "editor"]
  options:
    create_db_user_mode: keep

Now, instead of using shared accounts, each user gets their own database account, automatically provisioned and managed by Teleport. This not only enhances security but also makes it easier to trace specific database activities back to individual users.

Introducing Object-Level Permissions

As your organization grows, so does the complexity of managing database access. With multiple databases and roles, maintaining consistent and secure access controls becomes a significant challenge.

That's why Teleport has introduced object-level permissions. This feature allows you to define which specific objects (e.g., tables, schemas) a user can access, using a flexible label-based approach.

Here's an example of a developer role with object-level permissions:

version: v7
kind: role
metadata:
  name: developer
spec:
  allow:
    db_labels:
      environment: ["dev", "stage"]
    db_names: ["main", "metrics", "postgres"]
    db_permissions:
    - match:
        object_kind: table
      permissions:
      - SELECT
    - match:
        schema: scratchpad
      permissions:
      - SELECT
      - UPDATE
      - DELETE
      - INSERT
  deny:
    db_permissions:
    - match:
        schema: secrets
      permissions:
      - '*'
  options:
    create_db_user_mode: keep

In this example, Bob can read any table by default, modify the scratchpad schema, but he's explicitly denied access to the secrets schema. This level of control ensures that users only have access to the data they need, nothing more.

Visualizing Access with Teleport Policy

Managing access is one thing, but being able to audit and visualize it is just as important. Teleport Policy offers a powerful way to see who has access to what, and the most recent release (v16.2.0) now includes database object-level permissions in its visualizations.

For example, you can easily view Bob's access as a developer:

This visualization makes it clear which objects Bob can access and what level of permission he has for each. This transparency is crucial for both security teams and auditors, providing a clear overview of access across your entire infrastructure.

Custom Import Rules: Tailoring Access to Your Needs

Teleport's default import rules apply labels based on an object's inherent properties, like schema or database name. But what if your organization needs more granular control, based on custom criteria?

With custom import rules, you can define labels based on a wide range of properties, aligning access policies with your business needs. For example:

• A financial institution can manage access to market data based on licensing and compliance requirements.
• A medical research company can grant access to datasets on a project basis.
• A company can restrict user data access to personnel from specific locations.

These custom rules allow you to enforce access policies that are as unique as your organization.

A company can restrict user data access to personnel from specific locations. As an example, imagine a rule which prohibits non-EU personnel from accessing the EU-citizens data.

1. Partition the data. We must somehow separate non-EU and EU customers. A simple way is to put those in two entirely different databases. Another is to create country-specific tables.

2. Label the data. Use custom import rule to apply country-specific labels. We are pretty flexible here, you can match any combination of attributes (db name, schema etc.) to apply labels. This is to inform Teleport about the data partitioning scheme from the previous step.

Ultimately you want to have something like country: pl or is_eu: yes, depending on the granularity you want to go for.

3. Create deny access rule

You write an access rule that prohibits access to resources based on their labels. Assuming coarse is_eu label:

deny:
  db_permissions:
  - match:
      is_eu: "yes"
    permissions:
    - '*'

For more control, you can target specific list of countries.

4. Assign the deny rule to non-EU people.

Put the country of residence in the SAML/OIDC traits, fed from the upstream HR system. Assign the geo-based rules with the auth connector. If supported, the current location (based on geo-ip) can also be a factor, but this may be easily bypassed by using a VPN.

Conclusion

Teleport continues to push the boundaries of what's possible with Database Access Controls. With features like automated user provisioning and object-level permissions, you can manage database access with greater precision and security than ever before. Teleport Policy's integration further enhances your ability to visualize and audit access, ensuring that your infrastructure remains secure and compliant.

Whether you're a developer, a security professional, or an auditor, Teleport's evolving feature set empowers you to control and monitor access in ways that meet the demands of modern organizations.

Further Reading

• DAC RBAC
• Auto User Provisioning
• Teleport Policy