Root Access Policy

Root Access Policy (RAP)

Part of the Merlot Digital Legals
Last updated 2024/03/27 (March 27th, 2024)

This Root Access Policy (RAP) is a set of rules and conditions imposed on any access provided to Managed Servers at root-level. These rules explicitly define and restrict the ways in which the respective root/global-admin access can be used.

The Network Crew Pty Ltd T/A Merlot Digital’s RAP aims to clearly outline the situations where root access can be utilised, the extreme caution that must be taken at all times during all root-level access, and penalties for abusing and/or misusing root access to any Managed Server instances. Fully Managed service can only be rendered where you’re in compliance with this RAP as well as all other documents listed on our Legals page here.

This Root Access Policy (RAP) is an integral part of the policies to which each customer agrees to abide by when signing up for Managed Service/s with our company. Any violation of this RAP will be deemed a violation of our policies.

We, at our own discretion, shall determine whether an act constitutes a breach of this RAP’s terms and (therefore) misuse of our services. We reserve our right to be the sole arbiter in determining the sufficiency of the presented evidence/s. We will respond accordingly, and/or immediately terminate the provision of the service/s, shall we receive report and/or have sufficient proof of any prohibited conduct as outlined in the RAP, or any other activity threatening the security of our compute environment and/or our networking/etc infrastructure. Regarding termination, etc, there is a 2-strike policy that is defined further into this policy.

In order to protect our company’s reputation and responsibilities, and guarantee state-of-the-art and reliable Managed Services to all our partners/clients, as well as privacy and security for all users, we hereby outline the following RAP rules and conditions as being in effect for each customer signed up for a Managed Server (or several) with us:

1. Criteria to move from Reseller to Root access

Providing any type of Managed Service involves ensuring that the provider is able to guarantee a known-safe environment, one that matches or closely mirrors the relevant SOE for that deployment. Part of that comes down to ensuring that root-level access is reserved for genuine and appropriate use-cases only. We retain root-level access to all Managed Servers, providing Reseller-level access to our partners/clients, as this greatly reduces the risk of problems occurring due to our client/s making changes that aren’t compatible with the environment, or otherwise executing commands, installing packages, etc, that adversely interact with the known-stable environment. This is something we take very seriously.

For the majority of our partners/clients, they’re happy with Reseller-level access and are grateful to be away from the risks associated with root-level access. Some however will need root-level access for a variety of reasons – ie. process tracing, ensuring low-level access in the event of an emergency, and to facilitate easier migrations elsewhere should they decide to depart from our platforms (no hard feelings!). Where root access is required, a written request must be submitted to Merlot Digital outlining the reason/s behind the request, which would automatically (if approved) thereon be covered by this RAP and our other Terms, Policies and Agreements, as amended. This is non-negotiable.

It must be demonstrated or otherwise clear to us that you (our Client) are a technically-minded individual/business who understands the inherent risks of root-level access, and that your access/usage can and may be monitored and scrutinised to ensure on-going compliance with this RAP. If we have reason to believe your eligibility is no longer valid, your access will be reverted to reseller-level. Please see Section 6 for information surrounding the two-strike policy around non-compliance, though it’s important that you read the entire Policy.

Credentials must be kept adequately secured. Doing so must involve a known-secure password manager, ie. 1Password, and not an insecure system/practice (for example: Excel spreadsheet, LastPass, Word document, written note, and so on). We utilise static internet addresses from our sites, so can discern our access from all other activities easily.

2. Appropriate cases to utilise Root access

Examples of some appropriate use-cases to be upgraded from reseller-level access to root-level access include:

• Process tracing during application development, to aid in trouble-shooting faults/delays/hangs/panics/etc
• Facilitating self-service account transfers/migrations to/from machines in your solution, or elsewhere
• Ensuring accountability of the provider, in this case TNC, to make sure the right service is delivered

Note that this isn’t an exhaustive list, and that we may request supporting documentation/information before considering your request for elevated access.

Should your reasons for holding root access change or cease to exist, you need to notify us via Support Ticket within 3 business days of the change/s.

3. Ensuring our Engineers can investigate freely

A key reason why we keep the vast majority of our Managed Services partners on reseller-level access is to present issues when our team are trouble-shooting problems, as when you have several people investigating a system it’s more than easy to “bump into each other” and otherwise impact the other’s workflow. Engineers can become confused at results where a customer may have performed actions that led to questionable log entries that we then work to decipher. Where you may hold root-level access to a machine, when issues/queries occur you need to raise them with our crew as per normal (ie. email/ticket) and allow us to investigate. Holding root-level access does not permit you to revert to Self-managed behaviours in self-diagnosing faults – you need to always raise items with us properly, then allowing our team to deliver Fully Managed service to you by way of trouble-shooting, etc.

Should you desperately want to co-investigate a fault, this will need to be agreed in writing before you go-ahead, AND you will need to comply with any incident/ticket-specific requirements or restrictions that our crew specify, as they pertain to the involved software, set-up and so forth. You’ll need to explain what you plan to do and how you plan to do it, to ensure that our crew expect to encounter logs/history/behaviours surrounding those incident-approved checks on your end. As with other restrictions, not doing so makes up 1 strike.

4. Packages, monitoring, interference, etc

Due to the level of Fully Managed service we provide, you are never permitted to install packages as the root user on any Managed instance or machine with us unless you have approval in-writing via a Support Ticket. There are no exceptions to this rule, as installing software without approval can compromise stability, security, automation and beyond. Root access is provided on a trust-but-verify basis, so please expect your actions to be double-checked. If you are found to be removing evidence of your actions, Zero Tolerance applies (no strikes) and your root-level access will be removed. From that point, a dialogue/meeting/etc will need to be arranged to determine whether reinstating the access is safe for you & us.

Monitoring of your service/s will be provided as requested – this can be system-level or service-level. You are not permitted to configure any on-machine monitoring as it adds to the workloads on said machine 24/7, can behave unpredictably and hasn’t been verified to conform with the requirements of our SOEs as they apply to our system/s. Should you have any concerns around the monitoring and alerting over your service/s, please make contact with us so we’re able to deliver a solution that addresses your concerns & adheres to our Terms.

We deliver services with extensive security measures in-place, and require that no software which is deployed by us onto your service/s is amended or otherwise interfered with (ie. stopped, disabled, muted, reconfigured). An example would be the software firewall, opening additional TCP/UDP ports/ranges, or reconfiguring attack responses/actions/etc where it applies at that layer. This type of effort reduces security and leads to false-or-true warnings internally about problems, which leads to a cautious response, including re-securing root.

5. Accountability & Transparency (Rules)

Delivering root access to a Client with Fully Managed service/s comes with responsibilities that we’ve stepped out in this RAP – beyond that, it’s important to remember the core Linux principles around root-level access. This is included below – technically experienced clients will recognise the phrasing from many flavours of *nix.

We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things:

• Respect the privacy of others.
• Think before you type.
• With great power comes great responsibility.

This policy has already covered removing your history/commands/etc, and the approach we take to such behaviour. You can always verify commands before executing them, and your Fully Managed service is just that, so please don’t lose track and end up fighting fires rather than communicating. You need to be transparent, and to realise the power of root access.

If we uncover works performed by a client who holds root-level access where those works were not fully authorised ahead of time (or other extenuating circumstances applying, etc), we will have to consider this Policy. Please help us maintain a healthy working relationship where trust and honesty can remain in-place 24/7, removing any frustrations, confusion or similar. Where you’re evaluating the environment & have queries, you need to raise them via proper means in a polite way – Linux systems are complex & it’s easy to misinterpret data.

6. Violations of the RAP (2-strike policy)

Due to how important compliance with this Policy is with ensuring our service levels remain where they ought to be, we operate a 2-strike policy for non-compliance. Some incidents will incur a Zero Tolerance (ZT) approach, however that is rare and tends to involve chronic communication problems also (ie. tends to be used for immediate safety, to then discuss).

When your access level is changed to root-level, you will be kept on reseller-level access AND given access to root for situations where it is required ONLY. If you end up logging in as root all the time rather than being aware of needing the access and utilising it selectively, we have a problem. Should you expect that to be necessary, let us know why so we can discuss it – our security systems will alert us every time you engage the root account, so please don’t get in the habit of using root where it’s not required. Keep your systems safe!

If a client goes against this Root Access Policy and does NOT trigger a Zero Tolerance approach, using the point numbers as the Strike #, we:

1. Issue the client with a written 1st-strike warning, and potentially suspend root access for 15 days.
2. Issue the client with a written 2nd-strike warning, and potentially suspend root access for 60 days.
3. Remove root access from the client on a permanent basis, and offer a call/meeting/etc to discuss this.

Please understand that we’re more than reasonable in how we approach technical matters and negotiations, especially where the client is experienced (ie. of a technical background), and have this Policy in-place to safeguard services and end customers, as well as ensuring that we’re able to deliver premium service to you. If you have questions, we’re here for you.

7. Revisions to this document & others

We reserve our right to change this Root Access Policy (RAP) at any time, without prior notice.

We encourage our clients to periodically review this Root Access Policy and our other Terms, as use of our service/s implies expressed consent.