D2 · Access management

This procedure defines how access to Bolívar Connect is granted, used, reviewed and revoked. It applies to two types of access: personnel access to the infrastructure and the code, and client access to the API and the web portal.

1. Systems covered

System	Who has access	Authentication
AWS console and API	Authorized technical personnel	Named user + mandatory MFA
Servers	Authorized technical personnel	AWS SSM Session Manager (inherits IAM and MFA); no SSH or keys
Code repository	Technical personnel	Named account + MFA
Database	The application only	Service credential; no access from the internet
Platform operations	Security Officer	API key with admin scope, stored in AWS Secrets Manager
Operations console	Authorized personnel	Sign-in limited to the organization’s domains; roles, idle timeout and re-authentication for sensitive actions
Client web portal	Each client’s users	Single-use email link (expires in 15 minutes) or Google sign-in; roles per company (viewer, operator, admin), idle timeout and re-authentication for sensitive actions
Client API	Each client’s systems	API key with scopes, per tenant
Deployment	The server	Read-only, revocable deploy key

2. Principles

• Named accounts: personal accounts and credentials are not shared.
• Least privilege: access is granted by function and only to the system needed.
• Segregation of duties: the key that sends payment instructions is different from the read-only keys, and platform operations require a scope no client key has.
• MFA on all access to infrastructure and code.

3. Onboarding personnel

1. The area lead requests the access, stating the person, the system and the function.
2. The Security Officer approves the access and the minimum role needed.
3. Before receiving access, the person signs the confidentiality agreement and accepts policy D1.
4. The named account is created, MFA is enabled and the onboarding is recorded with the date, system, role and who approved it.

4. Role changes

A change of function is treated as removing the access that no longer applies plus granting the new access, with the same approval.

5. Offboarding personnel

On the day of departure the following is done:

1. Their accounts in AWS and the code repository are deactivated, and their active sessions are revoked.
2. Any shared credentials they had access to are rotated, if there were any.
3. The offboarding is recorded with the date and who executed it.

6. Client access to the API

• Each client receives its first API key when onboarded and can issue additional keys with limited scopes, for example read-only.
• Keys are shown only once and stored only as SHA-256 hashes.
• The client can rotate its key and its webhook secret at any time; the previous key is revoked instantly.
• Each key is subject to rate limiting and each tenant only accesses its own data.

7. Access review

• Per event: on every onboarding, offboarding or role change, as described above.
• Periodic: every quarter, the Security Officer compares the AWS and repository users and the platform credentials with the list of active personnel. Any access that cannot be justified is removed and the review is recorded.

8. Records

Onboardings, offboardings, changes and reviews are kept as evidence for at least the duration of the relationship with each person, plus one year. API key issuance and revocation are recorded in the platform’s audit log.