Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Here you go. Write me at jk@datapult.dk, if you need more.

A.5.25 Security in development and support processes:

Safe rolling deploy, rollback mechanisms, NGINX health checks, code versioning, Prometheus alerting for deployment issues

A.6.1.2 Segregation of duties:

Separate roles for database, monitoring, web apps; distinct system users

A.8.1.1 Inventory of assets:

Inventory management through Ansible inventory.ini and groups

A.8.2.3 Handling of assets:

Backup management with OVH S3 storage; retention policy for backups

A.8.16 Monitoring activities (audit logging, monitoring):

auditd installed with specific rule sets; Prometheus + Grafana Agent + Loki for system/application/audit log monitoring

A.9.2.1 User registration and de-registration:

ansible_user, restricted SSH access (no root login, pubkey auth), AllowUsers, DenyUsers enforced

A.9.2.3 Management of privileged access rights:

Controlled sudo, audit rules track use of sudo/su; no direct root access

A.9.4.2 Secure log-on procedures:

SSH hardening (no password login, no root, key-based access)

A.9.4.3 Password management system:

Uses Ansible Vault and variables;

A.10.1.1 Cryptographic controls policy:

SSL/TLS certificate generation with Cloudflare DNS-01 challenge, enforced TLS on Loki, Prometheus

A.12.1.1 Security requirements analysis and specification:

Tasks assert required variables and configurations before proceeding

A.12.4.1 Event logging:

auditd, Prometheus metrics, Grafana Agent shipping logs to Loki

A.12.4.2 Protection of log information:

Logs shipped securely via TLS to Loki, audit logs with controlled permissions

A.12.4.3 Administrator and operator logs:

auditd rules monitor privileged command usage, config changes, login records

A.12.4.4 Clock synchronization:

chrony installed and enforced on all hosts

A.12.6.1 Technical vulnerability management:

Lynis, Wazuh, vulnerability scans for Prometheus metrics

A.13.1.1 Network controls:

UFW with strict defaults, Cloudflare whitelisting, inter-server TCP port controls

A.13.1.2 Security of network services:

SSH hardening, NGINX SSL, Prometheus/Alertmanager access control

A.13.2.1 Information transfer policies and procedures:

Secure database backups to OVH S3 (HTTPS/S3 API)

A.14.2.1 Secure development policy:

Playbooks enforce strict hardening as part of deploy processes

A.15.1.1 Information security policy for supplier relationships:

OVH S3, Cloudflare services usage with access key/secret controls; external endpoint defined

A.16.1.4 Assessment of and decision on information security events:

Prometheus alert rules (e.g., high CPU, low disk, instance down, SSL expiry, failed backups)

A.16.1.5 Response to information security incidents:

Alertmanager routes critical/security alerts to email/webhook; plans for security incident log webhook

A.17.1.2 Implementing information security continuity:

Automated DB backups, Prometheus backup job monitoring, retention enforcement

A.18.1.3 Protection of records:

Loki retention policy, S3 bucket storage with rotation; audit logs secured on disk



Re: ssh, I'm going to also assume that the public-facing servers don't have ssh exposed publicly, or locked down so only accessible via bastion server -- or through a specific internal-only network or VPN/tailscale etc ?


Yeah, the SSH port isn't publicly exposed




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: