Architecture

Concept

The Mamori server is software solution made up of core services and three modules - M4IP, M4PAM, and M4APP. All module services are bundled into the one server install except for the M4APP HTTP/S proxy.

M4IP

M4IP is a zero trust network access solution (ZTNA) that uses wireguard tunneling technology, and turns the Mamori server into a bastion server. M4IP monitors, records, and injects security workflows into TCP communication protocol.

M4IP is highly-configurable and deployable in all common corporate network configurations. Four typical deployments models are:

Split Tunnel
Full Tunnel
Remote Access Only
Cloud Deployed

M4PAM

M4PAM is a privileged access management solution that uses proxy technology to monitor, record and inject security workflows into standard RDP, SSH and direct database communication protocols. Enabling enhanced security and access management without the need to deploy agents or requiring updates to servers, databases or endpoints.

How do admins access resources with M4PAM?

  • Users use their directory logins + Mamori 2FA to access databases and remote desktops. System credentials are never used.
  • Users use their public SSH key + Mamori 2FA to SSH to allowed hosts.

M4PAM Proxies

rdp proxy: protects remote desktop (rdp & vnc) traffic

ssh proxy: protects ssh & sftp traffic

database proxies: protects database wire-protocol traffic

M4APP

M4APP is the application security module and has two components:

  • A SAML provider that provides SSO/2FA for SAML enabled applications. One provider is bundled with the Mamori server, and addition providers can be installed separately for performance and redundancy.
  • An HTTP/S proxy that provides security and data privacy controls for applications. HTTP proxies are installed separately.



Mamori Server

The Mamori server is the main component of a Mamori deployment. It contains the ssh proxies, database proxies and all services required to configure and monitor your Mamori server and infrastructure

Deployment

method: docker container

location: on a server near the databases and servers to be secured.

download: click here to access dockerhub repo

Server Services

Mamori ServicesIn ContainerMin VersionDescription
DockerContainer Manager
Mamori CoreYes-Configuration Portal (nginx 1.20, phoenix/elixir 1.7.2)
Mamori SAMLYes-SAML provider (powered by Open SAML 4.1)
ProxiesYes-RDP, SSH, MySQL, SS, Oracle, Mongo, Postgres and other JDBC. HTTP/S Proxy (separately installed)
WireguardYes1.1Remote Access Firewall Tunnelling service. product link
PostgresYes14Configuration Store
InfluxDBYes1.8Activity Instrumentation Store. product link
GrafanaYes8.1Custom Dashboarding service. product link



Application Proxies

Application proxies are required to enable on-the-wire role based security and data privacy (masking) controls on applications and APIs without changes to the application. They are not required for 2FA SAML integration.

Deployment

method: jar

location: on a server near the applications to be secured.

download click here to download



SDK API

A set of JS bindings for the Mamori API that can use used to script common tasks and integrate with 3rd party solutions.

Deployment

method: git project

location: install where required

NPM click to access library

repository click to access github repo



Secret Management

Secrets stored by Mamori

  • Database credentials used to create a data source or granted to a user or role
  • Passwords of Mamori internal directory users
  • Hash of user passwords (required by protocols like Oracle)
  • SSH Keys
  • SSH login credentials
  • Remote Desktop credentials
  • Secrets stored in the secret vault
Mamori does not store the passwords for users from external directories.

Algorithm

Secrets are encrypted using a static AES-256 encryption key that is unique per Mamori server installation. By default this unique key is generated on installation.

To override the dynamically generated key with an external key, then prior to installation set the server environment variable MAMORI_ENCRYPTION_KEY with the desired key. After the installation remove the environment variable.



Compliance & Security Standards

Mamori delivers the technical safeguards required by data privacy and security regulation, but it itself does not require certification because it does not store or transact any financial, medical or personal identifiable information.

Click to access GDPR regulation coverage


Mamori is a self-hosted solution that meets security standards under a shared responsibility model between Mamori and the customer deploying the service.

Customer Responsibilities

  • The customer is responsible for securing the administration access to the Mamori server web portal and server operating system.
  • Upgrading the Mamori server to any required security patch build.
  • Multi-factor all administration access to the Mamori server via Mamori 2FA.

Mamori Responsibilities

  • Meet NIST encryption standards
  • Ensure all web based communication is via HTTPS
  • Ensure all proxies use their corresponding secure native database protocols
  • Ensure all network communication is encrypted secure via WireGuard
  • Ensure all code is regularly scanned for dependency vulnerabilities and patched
  • Ensure all secrets are stored encrypted
  • Record an imutable audit log of all service activity
  • Perform penetration tests daily builds



High Availability & Backups

The Mamori server can be deployed in two high availability modes:

  • Active-Active (Recommended)
  • Active-Passive
Our current sandbox demo environment is an Active-Active HA deployment.

Active-Active

The active-active deployment is the recommended configuration because it seperates out the configuration data store and application services.This improves the scalability of the solution and also simplifies the backups. Handling future growth is easy as more Mamori servers can be added with minimal effort.

  • Servers : 1 load balancer, N number of Mamori servers and 1 Mamori DB and analytics store

  • Fail-over :The load balancer will distribute traffic accordingly.

  • Backups :Take a snapshot of the load balancer and Mamori servers, and regular backups of the DB server.

  • Recordings :Recordings can be stored either on a shared network drive or on the Mamori DB server.

  • Logs :OS logs can either reside on the respective Mamori servers or be configured to stream to a corresponding location on the Mamori DB server.

Further redundancy can be added by converting the Mamori DB server into a PostgreSQL Cluster. This requires a commercial license of PostgreSQL

Active-Passive (Hot Standby)

The active-passive deployment is available when the active-active configuration can't be deployed. Handling future growth is done by increasing the amount of memory and cores of the Mamori servers. It is not easy to add more Mamori servers as the replication is fixed.

  • Servers : 1 load balancer, 2 Mamori servers and 1 analytics store

  • Fail-over :When the master Mamori server is down, the load balancer will automatically cut over to the slave. The slave will become the new master for the PostgreSQL replication.

  • Backups :Take a snapshot of the load balancer, and regular backups of the Mamori servers and analytics store.

  • Recordings :Recordings can be stored either on a shared network drive or on the analytics store.

  • Logs :OS logs reside on the respective Mamori server.

Diagrams

Mamori Server Services Traffic

Remote Access Workflow

Internal WAN Access Workflow

Database Proxy Workflow

M4IP - Split tunnel

M4IP - Full tunnel

M4IP - Remote Access Only

M4IP - Cloud Deployed

Edit this page on GitHub Updated at Wed, Mar 13, 2024
Overview Install Server