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 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:
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.
rdp proxy: protects remote desktop (rdp & vnc) traffic
ssh proxy: protects ssh & sftp traffic
database proxies: protects database wire-protocol traffic
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.
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
method: docker container
location: on a server near the databases and servers to be secured.
download: click here to access dockerhub repo
|Mamori Services||In Container||Min Version||Description|
|Mamori Core||Yes||-||Configuration Portal (nginx 1.20, phoenix/elixir 1.7.2)|
|Mamori SAML||Yes||-||SAML provider (powered by Open SAML 4.1)|
|Proxies||Yes||-||RDP, SSH, MySQL, SS, Oracle, Mongo, Postgres and other JDBC. HTTP/S Proxy (separately installed)|
|Wireguard||Yes||1.1||Remote Access Firewall Tunnelling service. product link|
|InfluxDB||Yes||1.8||Activity Instrumentation Store. product link|
|Grafana||Yes||8.1||Custom Dashboarding service. product link|
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.
location: on a server near the applications to be secured.
download click here to download
A set of JS bindings for the mamori API that can use used to script common tasks and integrate with 3rd party solutions.
method: git project
location: install where required
repository click to access github repo
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 are encrypted using a static AES-256 encryption key that us 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.
Mamori is a self-hosted solution that meets security standards under a shared responsibility model between mamori and the customer deploying the service.
- 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.
- 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)
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.
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.