Is Raff Secure? How Cloud Security Responsibility Works

In short

Raff provides the infrastructure controls needed to build a safer cloud environment, including network-level DDoS protection, firewall controls, private networking options, snapshots, backups, and recovery access through the web console.

But no cloud provider can secure everything inside a customer-managed virtual machine automatically. Security is a shared responsibility. Raff protects and operates the cloud platform; customers remain responsible for the operating system, user accounts, SSH or RDP access, application configuration, software updates, secrets, and backup recovery planning.

This distinction matters because vague security claims create the wrong expectations. A secure cloud setup is not created by one checkbox or one provider feature. It comes from combining infrastructure protection with disciplined server administration.

What Raff protects at the infrastructure layer

Raff operates the physical and cloud infrastructure underneath your virtual machines. The platform provides controls that help reduce common infrastructure risks and give customers practical ways to protect and recover their workloads.

Network-level DDoS protection

Raff includes network-level protection designed to help absorb and filter malicious traffic aimed at disrupting services. DDoS protection reduces infrastructure-level exposure, but it does not replace application security, rate limiting, authentication, or monitoring inside your workload.

Cloud firewall controls

Firewall rules help customers limit which ports and services are reachable from the public internet. A strong starting configuration normally exposes only the services the workload needs, such as HTTPS and carefully restricted administrative access.

A firewall cannot protect an application that is misconfigured or running vulnerable software. It should be treated as one layer in a broader security model.

Private networking

Private cloud networks allow supported Raff resources to communicate without exposing every internal service publicly. This is useful for separating application servers, databases, internal tools, and management services.

A database, Redis instance, or internal API generally should not be public merely because another server needs to reach it. Private networking gives teams a cleaner way to design those boundaries.

Snapshots, backups, and recovery paths

Security also includes recovery. Accidental deletion, failed updates, ransomware, application bugs, and administrator mistakes can be as damaging as external attacks.

Snapshots and backups help create recovery points, while the browser-based console provides another access path when SSH or RDP is unavailable. These tools reduce recovery risk, but customers should still define retention periods and test restores instead of assuming that a successful backup automatically guarantees a successful recovery.

What customers are responsible for

A Raff VM gives you administrative control. That control also creates responsibility.

Customers should manage:

• operating-system updates and security patches
• SSH keys, passwords, RDP access, and administrator accounts
• application authentication and authorization
• secrets, API keys, database credentials, and environment variables
• firewall rules inside the guest operating system where applicable
• services and ports exposed by the application
• database permissions and data-access policies
• malware prevention and application-level monitoring
• backup schedules, retention, and restore testing

Raff does not automatically inspect or securely configure every application installed inside a customer VM. A server can be deployed on protected infrastructure and still become vulnerable through an outdated package, weak password, exposed database port, leaked API key, or overly permissive account.

Secure connections depend on the protocol you use

The previous version of this article incorrectly suggested that every connection to a Raff VM used universal end-to-end SSL encryption. That was too broad.

Connection security depends on the service and protocol being used. Linux administrators should use SSH with strong keys and restricted access. Windows administrators should secure RDP access and use appropriate account controls. Web applications should use HTTPS with correctly configured TLS certificates. Private services should stay on private networks or localhost whenever possible.

The important rule is simple: do not expose an unencrypted or unnecessary service to the public internet merely because the VM has a public IP address.

What we do not claim without verification

Security documentation should be precise. Raff does not use this article to make universal claims about disk encryption, end-to-end encryption for every protocol, compliance certifications, or application-level protection unless those capabilities are explicitly documented for the relevant product.

That is intentional. Customers should be able to distinguish between a verified platform feature, a configuration they must implement, and a security requirement that may need additional products or professional review.

A practical Raff VM security baseline

For a new Linux or Windows VM, use this baseline:

1. Create only the administrator accounts you need.
2. Use SSH keys for Linux and strong, restricted administrator access for Windows.
3. Apply operating-system and application updates.
4. Close every public port that the workload does not require.
5. Place databases and internal services behind private networking where possible.
6. Keep secrets outside source code and public repositories.
7. Create backups before the workload becomes business-critical.
8. Test at least one restore before relying on the backup process.
9. Monitor login attempts, service errors, storage usage, and unusual activity.
10. Remove unused accounts, packages, services, and credentials.

This approach is more useful than assuming a cloud provider can make a customer-managed server secure without customer participation.

Security is a system, not a marketing claim

The safest way to evaluate a cloud provider is to ask specific questions:

• Which infrastructure protections are included?
• Which ports and networks can I control?
• How do I recover from a bad configuration or failed update?
• Which security tasks remain my responsibility?
• Are product claims documented clearly enough to verify?

Raff's goal is to provide practical infrastructure controls without pretending that infrastructure alone solves every security problem.

Use Raff Security to review platform protections, Private Cloud Networks to separate internal services, and Data Protection to plan snapshots, backups, and recovery.

:::cta Explore Security Review the controls available for protecting your Raff workloads. :::