Access as a process - purpose-based Access - Zero Trust for the rest of us

Tags: #<Tag:0x00007f173776b330> #<Tag:0x00007f173776b268> #<Tag:0x00007f173776b178> #<Tag:0x00007f173776b0b0> #<Tag:0x00007f173776afe8>

Access as a process - purpose-based Access - Zero Trust for the rest of us

In recent years tech-focused companies started to consolidate their development and operations organizations. Some followed the DevOps scheme more, others less.

For formative organizations that separated development from system operations (coding from system administration), IT compliance was less of a problem.
Today’s organizations follow cross-functional consolidation approaches. And things changed.

Segregation of Duties (related to ISO 27001 A 6.1.2 and other clauses) and avoiding end-to-end control by one single individual becomes a balancing question of Agile versus Agile (complex).

A certain lack of Segregation of Duties may be a minor business risk for a Startup, but once this venture has formative requirements, DevOps consolidation comes with compensating controls that introduce complexity. Once you go IPO… things can become different.

Definition of DevOps

Technically DevOps is focused on automation, and breaking down impactful changes into many small increments. Dare et impero.

This way Continuous Integration (incl. automated software-testing) and Continuous Deployments (incl. releases) become possibilities.

In order to keep DevOps lean and effective teams have their own responsibilities; for example within the overall hosting platform; often for their own platform-services. Platform-services can architecturally be broken down into Mirco-Services so that every part can get changed incrementally. First and foremost independently.

Independent… or self-sustained DevOps engineers may have OnCall duty so that the team can autonomously maintain services, which may have KPIs (Key Performance Indicators) like “99% uptime”; derived from the overall platform KPI.

Due to the cross-functional responsibility DevOps engineers need access to live databases, live services, production systems. They do development (Dev) and system operations (Ops). Simple… unless you have shared responsibilities. Or parts of the organization, that do not follow DevOps.

Purpose-based access - think process, think procedure, think pipeline- Agile in action

Not every DevOps organization is successful. Some companies failed to support the transition process or to properly analyze their business requirements in advance.

Compliance often defines the subset of Information Security that is a hard business requirement.
For the sake of this short article let’s assume that Segregation of Duties is a hard business requirement, regardless of whether it’s implemented within the ISMS (Information Security Management System) or directly as part of a business-controlling framework for financial compliance.

What if all centrally managed accounts only get enabled on-demand?

Illustration: purpose-based access - OnDemand account re-activation

Even though most people use credentials on a daily basis they don’t handle them like car keys or access cards. Handled in less secure manors credentials can become exposed via Malware or Attackers and the impact of that only becomes visible at a late state of compromise.

Credentials are used for authentication. – To proof your identity. They can consist of one or multiple factors (passwords and One-Time-Pad tokens).

From left to right the elements of this automation pipeline are:

  1. Users with credentials for authentication using systems of different form-factors (Laptop, Desktop, …)
  2. the Self-Provisioning system for authorization with Automation Scripts, which produces Tickets (optionally with an approval or review workflow) to document the Purpose. The tickets can, of course, be reported to account for Identity and Access Management
  3. Central Authentication Management - LDAP and / or Microsoft Active Directory
  4. Users get re-enabled for a period of time
  5. Production systems (blue) with security event-log traces and audit trails

Means of segregation, like a Virtual Private Network (VPN) between the user and production, aren’t illustrated.

Key assumptions for a successful access-provisioning workflow

  1. the credentials are stored in a Central Authentication Management system, like LDAP (for example FreeIPA) or Microsoft Active Directory
  2. the CI server (for example Jenkins) is fit for the purposes (availability, integrity, …)
  3. a separate Central Authentication Management system is used for user authorization at production systems. Disabling the user in production doesn’t disable the local system user or the user required at the Self-Provisioning system.
  4. authentication protocols (Kerberos, LDAP) use TLS (Transport Layer Security) with reasonably secure cipher suites.
  5. documentation (tickets) can get generated automatically

Proof Of Concept - prototype - implementation

Within this Proof Of Concept prototype, the key idea is to separate authentication from authorization.

  • Credentials are used for authentication
  • Authentication gives you a user level (user, group, privileges)
  • User levels define the set of authorized actions (admin actions should require elevated privileges)

Test environments - PoC based on Jenkins, Bash, FreeIPA and JIRA

Jenkins is a popular CI server, that acts like a Web-frontend for Cron. Bash is a scripting language, which is common for Desktop Linux systems. And FreeIPA is a free OpenSource LDAP server with an API.

Jenkins CI -> Bash -> FreeIPA

Using the FreeIPA API[1] with curl to disable a user:

if [ -z "$USER_FOR_STATUS_CHANGE" ]; then
    echo "access_user is required"
    exit 1

STATUS=$(curl -w "%{http_code}" -s -o result \
                        "$FREEIPA/ipa/session/json" \
                        -H "Content-Type: application/json" \
                        -H "Referer: $FREEIPA/ipa/ui/" \
                        -H "Accept-Encoding: gzip, deflate, br" \
                        -H 'Cookie: ipa_session=MagBearerToken=WABCb' \
                        --data-binary '{"method":"user_disable","params":[["'"USER_FOR_STATUS_CHANGE"'"],{"version":"2.230"}]}' \
                        --compressed -k)

if [[ STATUS -lt 300 ]]; then 
    echo "Successfully enabled user: $STATUS"
    cat result
    echo "ERROR enabling user: $STATUS"
    cat result
    exit 1

Enable and disable users accordingly. Jenkins can run build jobs with parameters.

Ticket-generation with Atlassian JIRA

Automated ticket-generation with JIRA can be straight forward:

Approval and the user ticket-validation based on JIRA workflows are not subject to this blog post.

Seamingless workflow - ssh wrapper CLI -> Jenkins

Issue the username as a parameter via a script (you can also use an SSH wrapper):

#!/usr/bin/env bash

echo "What is the reason for the access?"
read reason

curl "$JENKINS_URL:8080/job/Enable%20user//buildWithParameters?access_user=$ACCESS_USER" --data-urlencode "reason=$reason"

The maintainability of a workflow like this should be high enough for most organizations because the components are standard infrastructure.

Considerations for more mature implementations

In the PoC there is no evaluation of the provided reason for access:

Ticket references or approval status aren’t being checked. Users can always enable their provisioned account, use the existing credentials and gain the temporary access privileges they are entitled to via their existing group memberships (LDAP and OUs). These are not modified.

At a point, when we consider solving these shortcomings we have already begun to think about access as a process. And that is the reason why this blog post was written.


The exemplified and prototyped concept can be used to de-risk a company with a very small investment. If we start to think about access as a process and of Identity and Access Management as part of the perimeter many IT compliance objectives become easier to reach.
Keeping the balance between Agile and Agile-complex is simple if we adapt to a different mentality when we think of access.

In reality, it is often enough just to be a little smarter than the attacker. It is possible that a compromised endpoint exfiltrates data via the established VPN using the enabled user including the available privileges.
That scenario doesn’t impose a new risk. In modern DevOps organizations, only automation accounts should maintain permanent access. If attackers want to abuse purposely enabled internal accounts for data-theft they have to improve their timing.

You can tie purpose-based access provisioning to the VPN. For technical reasons, it is difficult to introduce internal reverse-proxies for enterprise tools like VMware VSphere[2]. The Zero Trust model has limitations with respect to its applicability. Not just regarding legacy systems.

Many organizations cannot deliver a clear definition of their DevOps program and its respective IT compliance. From the perspective of an Auditor, the absence of enabled accounts simplifies the assessment of many control objectives. Eventually, the tickets and their workflows need to be considered depending on further compliance objectives.

But if many people in the organization hold the “keys to the kingdom”, risks escalate. Here a DevOps transition can be a pitfall, and finding solutions means challenging established mindsets. In IT compliance, Information Security but also in Ops and Dev.

  1. ↩︎

  2. ESXi (6.5) - usage compendium for Road Warriors - a sample Nginx reverse proxy for the ESXi web ↩︎