ssm.ro Docs
Security, Infrastructure & OperationsInfrastructureAWS (Enterprise Model)

IAM AWS

Least-privilege IAM per deployment model; securely stored credentials; 2FA on the administrative account

Least-Privilege Principle

Access to AWS services within the SSM.ro platform follows the least-privilege principle: each component has exactly the minimum permissions required for its function — nothing more.


Shared Model (SaaS) — IAM Access

In the Shared model, SSM.ro uses AWS microservices (S3, API Gateway, Lambda, CloudWatch Logs) on shared infrastructure. IAM access follows least-privilege:

ComponentAWS Service AccessedPermissions
Web applicationS3 Primary bucketRead + Write on the application's bucket; no access to other buckets
Processing componentAWS CloudWatch LogsWrite-only (append) on the signing-dedicated log group
Processing componentAWS Lambda (via API Gateway)Invoke on specific functions
Administrative accountAll servicesFull access — protected with mandatory 2FA

Enterprise (Dedicated) Model — IAM Access

In the Enterprise model, the full suite of AWS services is used. IAM access is structured per role:

ComponentAWS Services AccessedPermissions
Application / serverS3 Primary bucketRead + Write on the application's bucket; no access to other buckets
Processing componentAWS CloudWatch LogsWrite-only (append) on the signing-dedicated log group
Processing componentAWS Lambda (via API Gateway)Invoke on specific functions
Administrative accountAll servicesFull access — protected with mandatory 2FA

IAM Credentials

  • Credentials are stored securely in the application's environment variables — not in source code
  • Separate sets per environment: production and staging use distinct credentials with different scope
  • Application credentials do not have administrator access — they cannot modify the AWS configuration

AWS Administrative Account

  • Mandatory 2FA on the administrative AWS account
  • Administrative access is used exclusively for configuration and operations, not by the application
  • Activity monitored via AWS CloudTrail (at account level)

CRR Replica — Access

The S3 CRR Replica bucket is configured so that no application has direct read/write access:

  • Replication is managed by AWS (managed CRR) — not by an application IAM identity
  • Access to the replica in a DR event requires explicit administrative access

IAM Credential Rotation

Upon a compromise event:

  1. Generate a new set of IAM credentials
  2. Update environment variables in production and staging
  3. Disable and delete the compromised credentials
  4. Verify that no other resource is using the compromised credentials