In order to deploy Athena platform on-premises, it is necessary to map on-premises infrastructure and solution architecture to Athena infrastructure and solution architecture

Infrastructure

Non functional requirements

If answer to question is yes, please provide details or documentation of a infrastructure feature (for example: username, password, API documentation for API to manage environment public domain zone).

If answer to question is no, please state that you acknowledge the risk (for example: end users can access all deployed web applications directly because there is no network firewall or there is a manual procedure and a contact of a person who can implement the changes) or that you want Athena platform to provide a particular infrastructure feature.

Personal Data protection

  • Is all application data stored on encrypted disk volumes?

Secure communications

  • Are all communications between end user machine and service endpoint encrypted?
  • Are there network firewall rules enabled to make sure that end users cannot access deployed web applications directly but only through authenticated, authorized and audited access point?
  • Are users always authenticated when accessing web application regardless of web application security settings?
  • Are users always authorized when accessing web application regardless of web application security settings?
  • Is there an audit log which shows which web applications were accessed by which user?
  • Is there API available to change network firewall rules?
  • Is there a public IP address for Web Application Firewall available and assigned to Bastion server instance?
  • Is there a public IP address for Virtual Private Network service available and assigned to Bastion server instance?
  • Is there a environment public domain zone available to establish reliable secure communications?
  • Is there a wildcard SSL certificate available for environment public domain?
  • Is there API available to manage environment public domain zone?
  • Is there VPN service available to enable direct access to server instances on per user basis?

Recovery

Resiliency

  • Is there a load balancer available?
  • Is there API available to setup new load balancer or configure existing load balancer to accommodate new web application requirements?

Disaster recovery

  • Are web applications deployed in resilient environment in two data centers?
  • Is load balancer available to automatically reroute end user requests to available data center should one of data centers fail?

Scalability

  • Is it possible to procure, add new server instances as needed in short period of time (less than one hour)?
  • Is it possible to retire extra server instances when not needed and pay for usage on per hour basis?

Deployment zones

In order to ensure information security, service availability and solution scalability different types of Athena services are deployed across different deployment zones.

Minimum requirement is to have one server instance per deployment zone with less than 24h availability requirements and two instances per deployment zone otherwise.

It is also possible to install multiple deployment zones on one server instance, but it will require an extra effort of creation of custom PLAY to install and maintain these services.

In case if there are less than minimum server instances available and it is necessary to mix deployment zones it is necessary to understand potential risks and operational issues.

Availability

  • It will be not possible to do rolling updates (deploy new service version, verify deployment, turn off old one and complete new version roll-out) if there are less than two server instances available per deployment zone.

  • It will be not possible to resize hardware (change disk space, change number of CPUs, etc) without a downtime if there are less than two server instances available per deployment zone.

  • In case of event of congestion co-deployed zone services, both zone services will be unavailable (for example if Public zone instances are under heavy load, it will be not possible to access Backoffice services to troubleshoot and mitigate possible issues, any Backoffice work-flows will be not available until Public service congestion reasons are found and mitigated).

Information security

  • In case of event of server instance penetration all co-deployed zone services are open to and easy attack vector (for example: if Public and Backoffice zones are co deployed, any public service breach will open an easy attack vector to Backoffice services, similarly if Backoffice and Internal services are co-deployed, penetration of Backoffice service will open an easy vector to directly access without a restriction of Internal service data files).

Scalability

  • Not all of deployed services are designed to scale horizontally. It can happen that scalable and not scalable services are co-deployed, what will lead to unpredictable results and server resource trashing (for example: if Public and Backoffice services are co-deployed and it is necessary to scale Public service automatically by restoring server instance snapshot on an extra instance, Backoffice services which are not designed to be scaled horizontally will waste new server instance resources and can misbehave in multiple ways, including service data corruption).

Host operating system

Currently Athena “out of box” supports Ubuntu server LTS as a host operating system.

All of Athena services can be deployed also on other host operating systems (such as Windows 2018 and RedHat or CentOS). Additional effort might be required to deploy some of these services.

Artifacts

Depending of what level of automation is available, these are artifacts necessary to enable access and automation features:

  • Platform owner public SSH key setup and enabled on target server instances (for example: for user ubuntu in case of Ubuntu server LTS)
  • Public domain zone
  • Public domain zone management API access credentials and documentation
  • Wildcard SSL certificate and key for the public domain
  • Network Firewall API access credentials and documentation
  • WAF Public IP assigned to Bastion instance
  • VPN Public IP assigned to Bastion instance
  • Load balancer API access credentials and documentation

Solution architecture

If answer to question is yes, please provide details or documentation of a solution architecture feature (for example: username, password, API documentation for log aggregation API, etc.) or state that it must be deployed by Athena.

If answer to question is no, please state that you acknowledge the risk (for example: we do not need centralised identity management, because we will deploy only one application or there is a manual procedure and a contact of a person who can implement the changes)

Deployment

  • Is it necessary to use tested, repeatable and well documented automated deployment?
  • Is it necessary to record a version of installed services and have a quick way to roll back previous version of the service if necessary?
  • Is it necessary to install and maintain multiple complex components (such as gitlab, freeipa, etc) on the same machine?
  • Is it necessary to have a local DNS service and installed application registry and to resolve dependent services by a name?

Maintenance, Monitoring and Security tools

Environment system user secrets

  • Is there a audited, encrypted data store for sensitive environment configuration, such as service user keys, certificates, service user usernames and passwords, so that it is possible to easily rotate, and share these secrets in a secure way?

Monitoring

  • Is it necessary to have monitoring tool which reports server instance usage (Disk IO, CPU, MEM, etc usage) via Web interface and API, to be able quickly in a secure way view server resource usage via Web browser without logging into a particular server?
  • Is it necessary to monitor server stats (memory, disk and CPU) and automatically send alerts to administrator if these thresholds are exceeded?
  • Is it necessary to monitor deployed service availability by checking if deployed service port responds to connection attempt and automatically send alerts to administrator if application is not responding?
  • Is it necessary to monitor all deployed application logs and in case of ERROR messages notify administrator?
  • It it necessary to aggregate all service logs into single repository, so that they can be easily viewed in appropriate context, searched and archived to off-site storage as necessary.

Identity management and LDAP provider

  • Is it necessary to have user identity directory (LDAP) shared for all deployed services, so that all application users would have same password and username across all deployed applications.
  • Is it necessary to have a single directory where all application users authorization rules (applications to which user have access) are defined?
  • Is it necessary to have easy self service for new user on-boarding?
  • Is it necessary to have easy self service for forgotten password?
  • Is it necessary to make sure that user passwords are never stored in unencrypted text and cannot be retrieved by anyone including system administrator?
  • Is it necessary to have easy and secure “one-click” way to disable users access to all applications at once?

Backup/Restore

  • Is there a backup and restore process tested and documented for deployed components data directories?
  • Is there API available to upload/download off-site (in different data center) backups.
  • Is it necessary to send system email notifications to end users (for example: forgotten password, item assigned, etc notifications).

Artifacts

Depending of what level of automation is available, these are artifacts necessary to enable access and automation features:

  • SMTP server API access credentials and documentation
  • Off-site backup API access credentials and documentation