On-Cloud / On-Premise Deployment Security

Mago on Cloud Security

Re Mago Meeting Server Separation of Duties and Least Privilege Security Principles

The principle of “Least Privilege” essentially means that users should not have more privileges than needed to complete their daily task. To secure data and the system in general from potential damage, it is essential to identify a comprehensive hierarchy of users and separate duties and to provide each individual with his or her own user ID and with permissions as minimal as possible to complete tasks.

RBAC Support and SoD

Re Mago Meeting Server support Role Based Access Control. Every meeting / workspace can be managed by a meeting owner who can control user permissions.

Microsoft Azure

Azure’s Data centres are geographically dispersed and comply to ISO/IEC 27001:2005, SOC 1 and SOC 2 and has CSA STAR certification. These Data centres are managed and operated by Microsoft who have decades-long experience building enterprise software and running some of the largest online services in the world. See the Reliability > Compliance section for more information.

SSL Rating

Mago Cloud has an A rating from Qualys SSL Labs, the highest ranking possible, which means it is protected from all known attacks and follows all best practices.

Mago on premises security

Microsoft IIS, Microsoft SQL and NTFS file system are legacy components needed for to deploy internal on-prem RMS architecture. Layer 7 firewall are strongly suggested in order to provide high level of security and 0-Day exploit explosion.

Purging policy for end-users data (State-less configuration for the RMS)

Re Mago Meeting Server can be configured to schedule a daily data wipe stored into the RMS secured storage partition. End-users data include all user activities media content, whiteboard content, workspace ID, workspace PIN and recap files.

Notes:

• RMS supports HTTP connections (LAN only), but we strongly recommend encrypted HTTPS over TLS 1.2.

• We do not directly tunnels any service. You can access resources only passing through our dedicated API interface and after passing a double level of authentication.

• We validate client inputs, verifying the presence of security tokens inside the HTTP headers and checking the content of the client calls.

• We implemented a strong custom authentication based on a double security token. The first token is released at the first call and is mandatory to retrieve the second token. The latest is verified at the beginning of each client call.

• We added rate limits to the authentication attempts that a client can do in a time unit. After this number/time limit, the attacker client is blocked.

Mago infrastructure scheme