The engineers have access to dozens of client-side applications. This requires protocol.

<aside>

Key people and communication:

• Access Security Owner: Philip Boontje
• Slack channel: #dev-{client_name}-data
• Email: [email protected] </aside>

Khalil Gibran – "If you reveal your secrets to the wind, you should not blame the wind for revealing them to the trees."

Typical setups

The majority of our projects are aimed at designing, building and maintaining client-side applications. Our vendor-agnostic modular approach to data architecture design usually results in a larger set of applications and vendors than a more single-vendor monolithic design architecture.

We distinguish different application access setups and by our experience we end up with all kinds of hybrid forms of each of the setups. We distinguish the following 4 setup types:

Setup 1: Direct to Application Access

Each project participant receives a dedicated personal client e-mail account and account access is managed on a per-person basis by using browser-enabled password managers. These kind of access work well for simple fast-in fast-out projects with little complexity.

graph TD
    %% Personal Accounts
    A1["Personal Account 1 <br> Client-specific"] --> APP1["Client App 1"]
    A2["Personal Account 2 <br> Client-specific"] --> APP1
    A3["Personal Account 3 <br> Client-specific"] --> APP4
    A1 --> APP2["Client App 2"]
    A1 --> APP3["Client App 3"]
    A1 --> APP4["Client App 4"]
    A2 --> APP2

    
    %% Client Applications

    %% Styling
    classDef account fill:#b3e0ff,stroke:#0066cc
    classDef vault fill:#ffcc99,stroke:#ff9933
    classDef app fill:#d9f2d9,stroke:#339933
    
    class A1,A2,A3 account
    class V vault
    class APP1,APP2,APP3,APP4,APPX app

Setup 2: Identity & Access Management

The client has setup an IAM architecture that control the access of individual personal accounts into all client applications. Through this setup, all logins are centrally managed by the IT department of the client, which makes access management more scalable and more secure. For some applications the direct access setup is still required, since not all security access can always be structured through a centralised IAM.

graph TD
    %% Personal Accounts
    A1["Personal Account 1 <br> Client-specific"] --> V["Identity and Access Management <br> Client-side"]
    A2["Personal Account 2 <br> Client-specific"] --> V
    A3["Personal Account 3 <br> Client-specific"] --> V
    A4["Personal Account 4 <br> Client-specific"] --> V
    
    %% Client Applications
    V --> APP1["Client App 1"]
    V --> APP2["Client App 2"]
    V --> APP3["Client App 3"]
    V --> APP4["Client App 4"]

    %% Styling
    classDef account fill:#b3e0ff,stroke:#0066cc
    classDef iam fill:#ffcc99,stroke:#ff9933
    classDef app fill:#d9f2d9,stroke:#339933
    
    class A1,A2,A3,A4,A5 account
    class V iam
    class APP1,APP2,APP3,APP4,APP5,APPX app

Setup 3: Vaulted access

For many situations the IAM setup is too inflexible and requires a more tailored centralised security access setup. In these situations you can create an encrypted database stored by the engineering company per client that has all access keys for the applications of a singular client.