Game Warden Secure Configuration Guide¶

This document outlines the mandatory application-level configurations and shared responsibilities required for software operating within the Game Warden DevSecOps platform.

To ensure transparency and compliance, this guide is made publicly available on the Game Warden Help Center and is formally included in our Certification package.

Top-level administrative accounts

Throughout this guide, top-level administrative accounts are defined as:

Tenant Application Owners: Individuals with ultimate authority over the application's configuration, deployment, and security posture.
Tenant Administrators: Individuals authorized to configure application-level access, assign roles, and manage integrations.

1. Identity & authentication (AuthN) management¶

Game Warden centralizes identity management to ensure all users access the system through highly secure, verifiable channels.

Centralized authentication	Your application must not handle local user authentication or maintain local user databases. All authentication is managed by Game Warden’s centralized identity service, Keycloak, utilizing supported federated protocols.
No embedded credentials	Unencrypted static authenticators, such as hardcoded passwords, API keys, or tokens, are strictly prohibited from being embedded in your application code or static storage.
Hardware-based MFA enforcement	The platform mandates phishing-resistant, hardware-based Multi-Factor Authentication (MFA) for all user access.

2. Application-level authorization (AuthZ)¶

While Game Warden handles authentication, your application is responsible for enforcing who can see and do what once they are inside.

JWT validation	Upon successful login, the platform injects a signed JSON Web Token (JWT) into the request. Your application backend must extract this JWT and cryptographically verify its signature using the public keys from Keycloak’s endpoint.
Claim-based access control	Your application must parse the JWT claims to enforce granular Role-Based (RBAC) or Attribute-Based Access Control (ABAC).
Multi-tenancy isolation	The platform does not natively enforce tenant isolation at the data layer; your application must use JWT group claims to strictly segment users and data by tenant.
Prohibition of shared accounts	Every user must be uniquely identified. The use of generic, shared, or group application accounts is strictly prohibited.

3. Session & account lifecycle management¶

Your application must be configured to respect strict session limits to prevent unauthorized access from unattended workstations.

Idle timeouts	Your application must enforce idle session timeouts of 30 minute sessions. Upon expiration, the application must reciprocate the logout, invalidate the session, and obscure the screen.
Concurrent sessions	Your application must support the platform’s strict limits on concurrent sessions, allowing a maximum of three (3) active sessions for privileged users and two (2) for non-privileged users.
Automated account deactivation	Users who do not actively authenticate for 30 days are automatically deactivated.
Emergency deprovisioning	You must maintain internal procedures to ensure that application access for terminated personnel is completely disabled within one (1) hour of their departure.

4. Network boundaries & data flow constraints¶

Game Warden enforces a strict zero-trust network architecture. Your application must be configured to operate within a "deny-by-default" network environment.

Approved external connections	Your application cannot route data to arbitrary external URLs. All required external endpoints must be formally submitted, reviewed, and recorded in the Approved Integration Registry prior to deployment.
Preventing data spillage	Application administrators must ensure that sensitive data is never routed, exported, or transmitted to unauthorized external systems or lower-security environments.
Secure token storage	Frontend developers must store JWTs securely in memory and avoid `localStorage` or `sessionStorage` to mitigate Cross-Site Scripting risks.

5. Cryptography & security telemetry¶

FIPS 140-validated cryptography	Game Warden encrypts all data at rest and in transit by default. If your application utilizes any custom cryptographic modules or self-managed encryption for data, it must strictly utilize FIPS 140-validated cryptography.
Audit logging	Your application must be configured to successfully generate and forward immutable application-level security logs (covering authentication events, privilege escalations, and data access) directly to the Game Warden Security Information and Event Management (SIEM).

6. Enhanced configuration & auditing capabilities¶

To ensure long-term configuration management and compliance auditing, Game Warden provides the following enhanced capabilities for top-level administrative and privileged accounts:

Secure defaults	The platform and its settings are provisioned with secure-by-default network, encryption, and container policies upon initial deployment.
Coming Soon Export and API capabilities	Customers are provided the capability to view, adjust, and export their current security settings and configurations via an API in a machine-readable format.
Coming Soon Configuration comparison	Using exported machine-readable data, customers and third-party tools can automatically compare their current application state against Game Warden's recommended secure defaults.