Skip to content

Advanced AWS Account Management

Overview

TechSologic runs UnoLock across multiple isolated AWS accounts with centralized identity and strict separation of duties. Account access is controlled through AWS Organizations and AWS IAM Identity Center, with tightly scoped permissions for developers, approvers, and operations.

This model is designed to reduce blast radius, prevent unauthorized production changes, and keep security-critical access paths narrow and auditable.

UnoLock runs on a fully serverless architecture with no customer-managed servers or host OS instances, which materially reduces host and network administration attack surface.

Account and Identity Model

  • Parent account governance: A parent AWS account managed through AWS Organizations controls identity and permission boundaries for child accounts.
  • IAM Identity Center control plane: Workforce identities and role assignments are managed centrally through IAM Identity Center.
  • Strong MFA posture: Access to AWS Access Portal requires physical YubiKeys.
  • Temporary credentials only: CLI/API access uses short-lived credentials from AWS Access Portal. No long-term AWS credentials are used.
  • No root-account operations: Day-to-day access is through users and roles only.
  • Root account lock-down: Root access is locked down and reserved for emergency use only.

Multi-Account Segmentation

UnoLock operations are segmented across account types:

  • Developer accounts: Each developer has their own AWS account and can deploy the full UnoLock app for end-to-end testing.
  • Build account: Hosts CodeCommit repositories and build pipeline infrastructure. Developers do not have access to this account.
  • Test account: Receives deployment from the approved pipeline and hosts the public test environment.
  • Production account: Hosts production deployment and is isolated from developer and approver access.

Regional Architecture and Recovery Model

  • Multi-region runtime: UnoLock production services are deployed across Canada and Ireland.
  • Multi-region public endpoints: UnoLock public application endpoints and API endpoints are deployed in both regions.
  • API Gateway scope: API Gateway is deployed multi-region for UnoLock API traffic.
  • Multi-region data layer: DynamoDB is configured for multi-region operation.
  • Multi-region key management: Root customer KMS keys used by the API server are configured for multi-region use.
  • PITR enabled: Point-in-time recovery is configured for 7 days and is part of the multi-region recovery model.
  • Disaster scope: Due to UnoLock's architecture, individual-account recovery is not the recovery target. Recovery procedures are designed for full multi-region disaster scenarios.

Access Boundaries and Separation of Duties

  • Branch-level write restrictions: Developers can push only to their own branches.
  • Protected master branch: Developers cannot write directly to master.
  • Pull request controls: Deployment updates begin with pull requests.
  • Independent approvers: Separate approvers in the build account control PR approvals.
  • Production isolation: Neither developers/operations nor approvers have direct access to the production account.
  • Highly restricted parent control: Access to the parent governance account is tightly restricted.

Logging and Retention Boundaries

  • Application operational logs (troubleshooting only): Retained for 3 days and limited to error/trouble-detection data used for production troubleshooting. These are not user activity logs.
  • AWS account audit logs (TechSologic access only): Organization-wide CloudTrail is configured in the parent account and delivered to Amazon S3, with a 365-day retention policy. This trail is used to audit TechSologic workforce access and AWS account activity, not customer application content.

Operational Benefits

  • Lower insider risk through role separation and minimal privileged access.
  • Reduced blast radius by account-level isolation.
  • Controlled change flow through protected branches and approval gates.
  • Credential risk reduction by eliminating long-lived credentials.
  • No direct infrastructure drift by routing all changes through pipeline controls.
  • Continuous dependency visibility through a separate nightly lockfile vulnerability scan with S3 reporting and SNS/SQS notifications.

FAQs

How is AWS access authenticated for TechSologic staff?

Access is authenticated through AWS Access Portal with physical YubiKeys, and sessions use temporary credentials.

Can developers modify production directly?

No. Developers are limited to their own branches and their own developer accounts. Production changes must pass through the approved pipeline and separate approval stages.

Where are identities and permissions managed?

Identities and permissions are centrally managed through IAM Identity Center in the AWS Organizations parent-account model.

Is the AWS root account used for normal operations?

No. Root is locked down and reserved for emergency access only. Routine operations are performed through role-based access with temporary credentials.

Integration with Other Features

  • Stateless Multi-Account Build System with AWS CodePipeline: Account management enforces the boundaries used by the deployment pipeline.
  • Serverless Infrastructure: Account controls complement UnoLock's serverless runtime model by limiting who can change infrastructure and deployment state.