Skip to content

Commit b3257cc

Browse files
committed
feat(use case): start security use case
1 parent 21e8f0d commit b3257cc

File tree

2 files changed

+68
-0
lines changed

2 files changed

+68
-0
lines changed
108 KB
Loading
Lines changed: 68 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,68 @@
1+
---
2+
title: Security baseline for Scaleway infrastructure
3+
description: TODO.
4+
tags: TODO
5+
dates:
6+
validation: 2025-10-31
7+
posted: 2025-10-31
8+
---
9+
10+
Scaleway offers a number of security features for your cloud infrastructure. This document sets out general best practices and advice, and highlights the security features available for different resource types.
11+
12+
## Network security
13+
14+
### Isolate and protect: strengthen security with VPC and Private Networks
15+
16+
We recommend that you **disable public connectivity** on all of your Scaleway resources, unless it is absolutely required. **Attaching resources to Private Networks**, and limiting their communication to these networks means that attack surface is minimized. The resource is no longer directly exposed to the internet, decreasing the risk of DDoS attacks, or unauthorized access.
17+
18+
For many resource types, including Instances, you can disable public connectivity by removing the flexible (public) IP address.
19+
20+
Create a layer 3 VPC, in which you can then create multiple layer 2 Private Networks and attach your resources to them. This enables secure communication between all resources in the VPC, away from the public internet.
21+
22+
Take some time to **consider and plan your network topology**, building your VPC infrastructure with **separation of concerns** in mind. Organize your resources into different Private Networks according to their function and usage, to enable easier troubleshooting, monitoring, maintenance, performance and scaling. For example, you may use one Private Network for frontend resources and another for backend resources. It may also be useful to create different VPCs for production and test environments, allowing you to isolate potential errors in testing from the production environment.
23+
24+
You can use resources such as Public Gateways and Load Balancers to **provide access to the public internet over Private Networks** where necessary. This allows Instances and other attached resources to send and receive packets to the internet through a single, secure point of access. You can use the Public Gateway's SSH bastion feature to connect to your resource via its private IP address.
25+
26+
You can set up a Network Access Control List (NACL) for each VPC. This allows you to define rules to limit the flow of traffic between the Private Networks of the VPC according to your needs.
27+
28+
See our use case on [basic infrastructure to leverage VPC isolation](/vpc/reference-content/use-case-basic/) for specific guidance, network diagrams and Terraform templates.
29+
30+
<Lightbox src="scaleway-vpc-infra-1.webp" alt="An architecture diagram shows how a Load Balancer inside a Scaleway VPC is attached to a Private Network. Also attached to the Private Network are three Instances (connected to Block Storage), a Managed Database, and a Public Gateway." />
31+
32+
### Precision traffic control: secure public interfaces with security groups
33+
34+
Security groups act as virtual firewalls for your Instances, controlling traffic over the public interface. You can define your own custom rules in each security group, to accept or drop inbound / outbound traffic based on protocol, port, and IP range. When you add an Instance to the security group, the rules you define are enforced on all traffic over its flexible (public) IP address.
35+
36+
This feature ensure that only authorized public traffic reaches your servers, significantly reducing the attack surface. Their flexibility and reusability across multiple Instances make security groups an efficient and scalable way to enforce consistent security policies in your Scaleway infrastructure.
37+
38+
A default security group is auto-generated for each Availability Zone you create an Instances in. All your Instances within that Availability Zone are automatically added to that default security group. The default security group rules allow all inbound traffic, and drop outbound SMTP traffic. We encourage you to customize your security groups in order to maximise control over your Instances' public interfaces.
39+
40+
## Protection at the edge: secure applications with Edge Services WAF
41+
42+
If you put a Load Balancer in front of your Instances and other resources, you can add an Edge Services pipeline to benefit from an inbuilt Web Application Firewall (WAF). This provides robust protection against common web-based threats such as SQL injection, cross-site scripting (XSS), and DDoS attacks.
43+
44+
By filtering malicious traffic at the edge, before it reaches your infrastructure, the WAF significantly reduces the attack surface and safeguards your backend resources. Integrated directly with the Load Balancer, the WAF ensures high availability and low-latency inspection of HTTP/HTTPS traffic, enabling real-time threat mitigation without impacting performance. With customizable security rules and managed rule sets, you can tailor protection to your application’s needs while maintaining full control. This setup not only enhances security but also simplifies compliance and improves resilience—keeping your applications secure, stable, and always online.
45+
46+
### DDoS protection
47+
48+
## Identity and Access Management
49+
50+
### Permissions and API keys
51+
52+
### Two-factor authentication
53+
54+
### Disabling password login; using SSH keys only
55+
56+
## Monitoring and logging
57+
58+
### Cockpit
59+
60+
### Secret Manager
61+
62+
### Audit trail
63+
64+
65+
66+
Enabling firewalls by default (allow only required ports)
67+
68+
Enabling automatic security updates

0 commit comments

Comments
 (0)