AMU Technical Architecture & Infrastructure Compatibility Brief

Executive Summary

The AMU solution is proposed as a secure, browser-based internal application for managing assets, cases, documents, movements, custody information, reporting, user access and auditable activity.

The prototype defines business workflows and user experience. This brief is intended to align the production implementation with Government IT's approved infrastructure before the final production architecture is locked.

Contents

What AMU Needs the System to Do

• Provide authenticated internal access to authorized AMU personnel.
• Maintain structured records for assets, cases, source agencies, movements, custody, contacts and related operational data.
• Store and retrieve protected documents and media, including PDFs, photographs, scans and other approved attachments.
• Enforce role-based access so users see and perform only functions authorized for their role.
• Maintain audit records for significant user and system activity.
• Generate operational and compliance reports and support controlled export/printing where authorized.
• Support secure integration with approved identity, email, storage, logging and infrastructure services where required.

Proposed Application Technology Stack

The following describes the current technical direction. Development tools do not automatically become production dependencies.

High-Level Architecture

AUTHORIZED AMU USERS
        ↓
GOVERNMENT-APPROVED IDENTITY / MFA
        ↓
AMU WEB APPLICATION
React / Next.js / TypeScript
        ↓
AMU SERVER / API LAYER
Developer-built application logic, validation & authorization
        ↓
PostgreSQL Database  ─  Protected File Storage  ─  Audit / Logging
        ↓
APPROVED GOVERNMENT SYSTEM APIs / INTEGRATIONS (where required)
        ↓
GOVERNMENT-APPROVED HOSTING, NETWORK, SECURITY,
BACKUP, MONITORING & RECOVERY CONTROLS

Production Capabilities Required from Government IT

Government IT may satisfy these requirements using its existing approved products and infrastructure.

Application Security Controls in the Build

• Authentication integrated with the approved identity mechanism.
• Role-based authorization enforced on protected operations, not only hidden in the interface.
• Least-privilege access for application roles and service identities.
• Server-side input validation and safe database access practices.
• Controlled file upload, file type/size validation and authorization before document access.
• Secure session handling and protection of authentication tokens/cookies.
• Secrets kept out of source code and repositories.
• Audit logging for defined sensitive and administrative actions.
• Dependency and source-code security scanning during development where available.
• Separate development/testing and production configuration.
• Security requirements reviewed against an accepted application-security baseline such as OWASP ASVS, subject to Government IT standards.

Development vs. Government Production

API & Integration Responsibility

The AMU application will include its own server-side API layer. This API is part of the application code and will be designed and developed by the Digital Solutions Architect/Developer. It is not a separate Government product that IT must build.

Government IT / Security is responsible for approving or providing the production environment in which that API operates, including hosting, network exposure, identity/service authentication, certificates, secrets, firewall/private-access rules, monitoring, logging and deployment/security standards.

Information Requested from Government IT

Please provide or confirm the following before the AMU production architecture is finalized.

1. What hosting environment is approved for the AMU application (on-premises, Azure, private cloud, another approved environment, or a combination)?
2. Is PostgreSQL supported? If yes, what versions and deployment model are approved?
3. Is a Node.js-compatible application runtime supported? Are there approved versions or runtime restrictions?
4. Are containerized applications such as Docker supported or preferred, or is direct server deployment required?
5. What identity provider is used for staff authentication (for example, Microsoft Entra ID/Active Directory or another approved service)?
6. Can AMU integrate with that identity provider for Single Sign-On (SSO) and Multi-Factor Authentication (MFA)?
7. What storage service is approved for documents, images, scans, videos and related attachments?
8. What encryption, certificate, key-management and secrets-management standards must the application follow?
9. What network access model is required: internal network only, VPN, approved remote access, private-cloud access, or another model?
10. What backup, retention, restore-testing and disaster-recovery requirements apply to the database and file storage?
11. What application/security logging and monitoring platforms must AMU integrate with?
12. What approved email/SMTP/API service should be used for notifications or internally generated reports?
13. What vulnerability scanning, application-security testing, code review or security approval is required before production?
14. What is the required process for moving releases through Development → UAT/Testing → Production?
15. Are there Government coding, API, accessibility, database, records-retention or application-security standards that must be followed?
16. Where must final source code, database migration scripts and technical documentation be stored or transferred?
17. Are external development services permitted for non-production work, and what restrictions apply to data used in those environments?
18. Are there restrictions on open-source frameworks, third-party packages, licenses or software dependencies?
19. What are the expected availability, performance, storage-capacity and file-size requirements for the AMU system?
20. Who should serve as the Government IT/security technical contact for architecture review, environment provisioning and deployment?
21. What standards must the AMU application follow for internal API authentication, authorization, endpoint security, versioning and logging?
22. Must AMU application APIs remain private/internal only, and what network controls or gateway/WAF requirements apply?
23. If AMU needs to connect to an existing Government system, who owns that integration and who will provide the approved API/interface specifications, credentials and technical documentation?
24. Are service accounts, managed identities, API keys, OAuth/OIDC tokens, mutual TLS or another method required for system-to-system authentication?

IT Compatibility Response Sheet

Government IT may use this section as a concise response checklist. Additional technical notes can be attached where necessary.

Proposed Responsibility Boundary

Editable Government IT Response Form

For ease of technical review, Government IT may complete the separate editable Word response form and return it by email. The form mirrors the compatibility questions in this brief and provides dedicated fields for requirements, integration contacts, comments and review status.

Requested Next Step

Technical Review Sign-Off / Comments