Security Implementation Guidelines¶

ARTESCA object storage clusters, whether mono- or multi-site, can be vulnerable points in the network if not properly secured. This document provides a comprehensive threat model, risk assessment, responsibility overview, and actionable implementation guidelines for administrators.

Threat Model¶

Assets¶

Data: The core asset is the data stored on the storage cluster, which could include sensitive personal information, financial records, confidential business documents, or intellectual property.
Device itself: The cluster hardware and its firmware are also assets that need protection. Compromise of the device can lead to data loss or alteration, or the storage system being used as a platform for further attacks on the network.
Network access: The connections of the storage clusters to the network allow access to other devices and resources, making it a potential stepping stone for attackers.

Threat Agents¶

External attackers: Cybercriminals motivated by financial gain, espionage, or disruption. They may exploit vulnerabilities to steal data, install ransomware, or use the storage cluster for malicious activities like hosting phishing websites or distributing malware.
Internal actors: Malicious insiders with access to the network, such as disgruntled employees, can pose a threat by intentionally deleting or altering data, or by exceeding their authorized access.
Accidental threats: Unintentional data loss or corruption can occur due to user errors, hardware failures, or software bugs.

Threat Actions¶

Unauthorized access: Gaining access to the storage cluster and its data without permission. This could be through brute-force attacks, exploiting vulnerabilities in the cluster software or hardware, or social engineering.
Data breaches: Stealing, modifying, or deleting data stored on the storage system.
Malware infections: Infecting the solution servers with malware, such as ransomware, spyware, or botnet malware, to compromise data or use the storage service for malicious purposes.
Denial of service (DoS): Disrupting the availability of the storage cluster and its data by flooding it with traffic or exploiting vulnerabilities to crash the system.
Physical theft: Stealing the physical storage system device to gain access to the data.

Vulnerabilities¶

Weak credentials: Using default or easily guessable usernames and passwords.
Software vulnerabilities: Exploitable bugs in the storage cluster server’s operating system, firmware, or applications.
Unpatched systems: Failing to install security updates and patches.
Insecure network configuration: Using insecure protocols (like FTP) or having weak firewall rules.
Lack of access controls: Not properly restricting user access and permissions.
Physical insecurity: Lack of physical security measures to protect the storage system physical devices from theft or tampering.

Threat Scenarios¶

Ransomware attack: An attacker exploits a vulnerability to gain access to the storage solution and encrypts all the data, demanding a ransom for the decryption key.
Data breach: A weak password allows an attacker to access the storage solution and steal sensitive data.
Credential stuffing: Attackers use leaked credentials from other services to try and gain access to the storage solution.
Insider threat: A disgruntled employee deletes critical data from the storage cluster.

By understanding these potential threats and vulnerabilities, it is possible to take appropriate steps to secure the storage solution devices and protect their valuable data.

Risk Assessment and Management¶

Security starts with the comprehensive knowledge and understanding of the threats related to a system. While it is impossible to create an entirely secure system, a clear picture of potential risks allows us to direct resources effectively to secure the most critical parts of the platform and prepare efficient response plans in the event of a breach.

Risk Identification¶

Typical risks for the storage platform are subdivided into network-related and physical access categories.

Network-Related Risks

Host Compromise: An attacker compromises a node to utilize its resources for malicious activities such as crypto-mining, DDoS attacks, or as a pivot for future targeted attacks.
Ransomware (Client-Side): An attacker utilizes legitimate client access credentials to encrypt data stored on the cluster.
Ransomware (Server-Side): The underlying OS or connector is compromised. This can range from non-targeted attacks that cause service interruption to targeted attacks capable of propagating to storage nodes, leading to massive data loss.
Application-Level Attacks: A targeted attack on the services running on top of the storage layer, aimed at modifying content or granting illegal access rights.
Storage Targeted Attack: Specifically targeting the storage host to gain deep access to the storage ring using standard administrative documentation.

Physical Access Risks

Active Server Access: Unauthorized physical access to a running server within the cluster.
Offline Server/Media Access: Access to a server that is powered off or the physical theft of a disk removed from its server slot.
Attack on Hosting Infrastructure: Induced or accidental disruption on data-center power, network, or physical integrity leading to service downtime or data destruction.

Risk Assessment Matrix¶

The following table summarizes the primary concerns and the potential impact on the storage infrastructure:

Risk Category	Attack Vector	Potential Impact
Data Loss	Ransomware, Physical Theft	Permanent loss of mission-critical information.
Data Leakage	Credential Theft, Unsecured APIs	Unwanted exposure of sensitive company information to third parties.
Compromised Services	DoS, Authentication Cracking	Denial of service or data corruption leading to falsified authentication.

Risk Management and Mitigation Strategy¶

Scality recommends a holistic approach to risk management, combining architectural design with strict operational procedures.

Primary Defense Layers

Network Segmentation: Careful attention is paid to the partitioning of solution zones. Storage nodes belong to a protected zone not accessible to public users.
Least Privilege & IAM: Access is restricted based on the “Need to Know” principle. This includes using IAM roles for temporary credentials and enforcing strict password policies to mitigate credential theft.
Immutability: To neutralize ransomware, the platform utilizes Object Lock (Compliance Mode) to ensure that critical backups cannot be altered or deleted by any user, including administrators, for a set period.
Encryption at Rest: Encryption is strongly recommended to mitigate physical theft. It is vital that encryption keys are not stored on the same server as the data.
OS Hardening: Utilizing pre-hardened operating systems (e.g., CIS Benchmark) and Mandatory Access Control like SELinux in Enforced mode to limit the scope of a potential host compromise.

Continuous Maintenance

Credential Hygiene: Regular rotation of access keys and immediate revocation of unused accounts.
Personnel Monitoring: Careful attention to changes in personnel who have high-level system access.
Audit Readiness: Regular audits of security settings and log monitoring to ensure no configuration drift occurs over time.
Keeping Software up to Date: Updating when prompted reduces potential vulnerabilities.

Responsibilities¶

To ensure the long-term security and operational integrity of the storage cluster, it is essential to establish a clear Shared Responsibility Model. While Scality provides the pre-hardened operating system and the storage software, the customer (administrator) is responsible for the configuration and daily hygiene of the environment.

Responsibility Overview¶

Scality’s responsibility ends at the delivery of a secure “trusted computing base”. The customer is responsible for the “security in the cluster”, which includes managing identities, protecting physical access, and ensuring that network perimeters are correctly configured to prevent unauthorized routing to the storage layer.

RACI Matrix¶

This matrix defines the roles between Scality (the Software/OS provider) and the Customer (the System Administrator).

Task / Activity	Scality (Provider)	Customer (Admin)	Description
OS Hardening & Stripping	R/A	I	Automatically stripping unnecessary packages and enforcing CIS benchmarks.
Physical Data Center Security	n/a	R/A	Controlling physical access to appliances and audited cable paths.
Initial Credential Rotation	C	R/A	Changing default OS and IPMI credentials during first boot.
Network Micro-Segmentation	R	A/C	Dynamic firewall management via Calico; customer must ensure no conflicting managers (ufw/firewalld) are installed.
IAM & S3 Policy Management	I	R/A	Mapping privileges via IAM Groups and implementing secret rotation.
Object Immutability Config	C	R/A	Enabling Object Lock (Compliance/Governance) for ransomware protection.
Internal PKI & Certificates	R	A/C	Provider delivers the subsystem; Customer must force renewals and manage CRLs.
Security Patch Provision	A/R	I	Providing updates.
Security Patch Deployment		R/A	Customer is responsible for scheduling the application of patches.

R (Responsible): The party who performs the work.
A (Accountable): The party with ultimate ownership.
C (Consulted): Parties whose opinions are sought (two-way communication).
I (Informed): Parties who are kept up-to-date on progress.

Implementation Guidelines¶

Executive Summary¶

As an ARTESCA customer and system administrator, securing your data storage infrastructure requires treating your storage nodes as a hardened, zero-trust environment. ARTESCA provides robust built-in mechanisms to ensure cyber resilience and data immutability against ransomware and insider threats. Because the product automatically enforces strict operating system hardening and network micro-segmentation, administrators can focus directly on configuration, identity management, and S3 protocol security. To establish a secure perimeter and maintain data integrity, administrators MUST and SHOULD adhere to the following guidelines.

Hardware Security, Out-of-Band Management, and Perimeter Defenses¶

Physical and environmental access controls form the foundation of your trusted computing base.

Physical Access and IPMI Management

MUST strictly control physical access to the ARTESCA hardware appliances. Ensure nodes are securely racked with audited cable paths.
MUST isolate the Intelligent Platform Management Interface (IPMI) traffic to a dedicated, heavily monitored out-of-band management network. IPMI interfaces must never be exposed to the general corporate network or the public Internet.
MUST change the factory default IPMI credentials immediately upon initial front-end network configuration.

Console Access and Default Credentials

MUST log in to the operating system console during the first boot to immediately change the default OS credentials for root and artesca-os users.

Network Perimeters

SHOULD encapsulate the ARTESCA deployment within a rigid Virtual Private Cloud (VPC) or equivalent logical perimeter, ensuring that only explicitly authorized internal network endpoints can route traffic to the storage layer.

Network Micro-Segmentation and Firewall Configuration¶

ARTESCA uses Calico to dynamically manage internal intent-based network firewall rules via Linux iptables. The ARTESCA internal firewall defines distinct rules for the control plane (management and cluster self-healing) and the workload plane (heavy data ingestion).

MUST NOT install, configure, or activate third-party or legacy firewall managers such as firewalld or ufw on the ARTESCA nodes. Doing so will conflict with Calico, leading to catastrophic network partitioning and cluster failure.
SHOULD leave the default Calico firewall rules enabled. These rules strictly govern the separation of the planes and enforce a least-privilege port access model.
MUST ensure that infrastructure monitoring tools only access from APIs on port 8443 or Ingress Health Check as per the monitoring section of the documentation.

Built-In OS Hardening and Password Management¶

ARTESCA’s underlying OS is customized and natively pre-hardened based on the CIS Rocky Linux Benchmark. Because the system automatically strips unnecessary packages and inherently blocks privilege escalation attempts, your primary OS-level responsibility is credential hygiene.

MUST adhere to the built-in, unalterable password constraints applied to all local accounts. Knowing these rules is critical when setting up new users or rotating credentials:
- Minimum password length: 14 characters
- Maximum same consecutive characters: 3
- Maximum sequential characters: 3
- Password complexity: require at least 1 character in every 4 character groups:
  Lowercase
  
  Uppercase
  
  Numbers
  
  Special Characters
- Password present in dictionary: no
- Password enforced for root: yes
- Password history: 24 passwords remembered
- Password difference: 2 characters different from the previous password
- Account lockout: 3 invalid login attempts in 15 minutes
- Account lockout duration: 900 seconds (15 minutes)
- Password expiration warning: 7 days
- Password expiration: 365 days

Identity and Access Management (IAM) Operations¶

Managing programmatic and user access to the S3 API requires strict credential hygiene.

MUST implement automated secrets management for programmatic access keys (Access Key ID and Secret Access Key).
MUST proactively audit and rotate access keys, aggressively deleting keys that have remained unused for extended periods (e.g., 90 days).
SHOULD utilize IAM Roles to grant temporary, ephemeral security credentials for applications, minimizing the footprint of long-term static keys.
MUST secure the management of S3 endpoints with TLS-encrypted HTTPS transmission from client to protect bearer access tokens from network interception.

S3 Authorization: IAM Policies vs. S3 Bucket Policies¶

Permissions are calculated as the least-privilege union of IAM policies and Bucket policies.

MUST utilize explicit Deny rules within your policies to create fail-safes. An explicit Deny universally overrides any overly permissive Allow granted elsewhere in the system.
SHOULD use IAM Policies for centralized user permission management, multi-bucket application access matrices, or when integrating with AD/LDAP federation.
SHOULD use S3 Bucket Policies when you need to enforce strict perimeter constraints (e.g., denying access if the request does not originate from a specific internal IP subnet), to grant cross-account data sharing, or when complex rules exceed the strict IAM JSON size limits.
SHOULD use ARTESCA assistants when available to ensure setting up proper minimal authorizations to ISVs (external applications) using the S3 storage.

S3 Protocol Hardening and Bucket-Level Defenses¶

Securing the S3 protocol is the most direct way to prevent data breaches.

MUST enforce the “Block Public Access” setting universally at both the high-level account and individual bucket levels to prevent accidental data exposure due to misconfigured Access Control Lists (ACLs).
SHOULD enable S3 Bucket Versioning for all buckets containing critical operational data to ensure previous states can be recovered after accidental or malicious modification when the client application supports versioning management.

Ransomware Neutralization via Immutability (Object Lock)¶

Object Lock provides mathematically enforced immutability, making your backups tamper-proof.

MUST configure targeted backup buckets as Immutable Buckets during creation to enable native S3 Object Lock.
MUST utilize Compliance Mode for critical backup data. In Compliance mode, no user — including the root administrator — can alter, overwrite, or delete the object until the defined retention period strictly expires.
SHOULD use Governance Mode only for internal testing or lower-tier data, as administrators with the s3:BypassGovernanceRetention permission can bypass the lock.
MUST recognize the architectural constraint: Cross-Region Replication is explicitly not supported on buckets where Object Lock is enabled. If you require highly available immutable backups across sites, you MUST configure your upstream backup application (e.g., Veeam) to write independent immutable copies to both sites simultaneously.

Replication Workflows and Data Lifecycle Management¶

For non-immutable data requiring geographic redundancy or capacity management:

SHOULD utilize Active-Passive (uni-directional) or Active-Active (bi-directional) asynchronous replication workflows for disaster recovery of standard data.
MUST configure appropriate destination-side IAM ACLs, as cross-account replication may require explicit destination permissions to access the replicated data.
MUST implement automated S3 Lifecycle Expiration policies to systematically purge stale data, abort incomplete multipart uploads, and securely expire non-current object versions to minimize your long-term attack surface.

Cryptographic Subsystems (Encryption at Rest and in Transit)¶

MUST mandate secure S3 connections routed exclusively over HTTPS utilizing modern TLS protocols.
MUST when using delegation of the endpoint certificate to ARTESCA, Certificate Revocation List (CRL) is managed automatically. Otherwise it is required to proactively manage the system’s CRL and regularly force the renewal of ARTESCA’s built-in internal certificates to maintain the chain of trust.
SHOULD enforce Server-Side Encryption (SSE) for all data at rest.
- Use SSE-S3 (Amazon S3 Managed Keys) for zero-overhead, transparent default encryption.

Telemetry, Audit Logging, and Incident Response¶

Preventative security requires continuous detective capabilities and forensic readiness.

MUST NOT leave the internal Loki log aggregation tool enabled during standard operations. Because Loki parses distributed logs in real-time, it can induce severe CPU and load spikes.
MUST verify that node memory utilization is < 90% and system load is < 100 before enabling Loki via the salt-call command for a time-bound forensic session.
MUST actively monitor the Loki storage partition when enabled; if it approaches capacity, you MUST disable it immediately to prevent cluster denial-of-service.
MUST use the sosreport utility to extract detailed forensic archives during an incident. After generation, you MUST change the ownership of the compressed archive back to the artesca-os user before transmitting it securely via SFTP to Scality Support.

Software Lifecycle¶

MUST upgrade ARTESCA software within 30 days of receiving notification of a new release.
MUST subscribe to the Scality Security Technical Bulletin channel Scality Support to receive proactive security announcements.