Transparency is part of the product. This page explains exactly how SecureLuna connects to your servers, what data it reads, what it stores, and the things it will never do.
1. Connection Model
- You register a server you operate (host, SSH user, port).
- SecureLuna generates an Ed25519 SSH key pair on our side. You receive the public key.
- You install the public key on your server (typically appending to
~/.ssh/authorized_keys). - Each scheduled run, SecureLuna connects via SSH and runs read-only commands defined by the rule library.
- Output is parsed into pass/fail per rule and stored in our database.
2. What We Read
SecureLuna reads only the configuration and state needed to evaluate a checklist item. Examples:
- Sudoers file content (
cat /etc/sudoers,cat /etc/sudoers.d/*). - Password policy (
cat /etc/login.defs). - SSH server configuration (
cat /etc/ssh/sshd_config). - Firewall settings (
iptables -L,ufw status, etc.). - Audit / logging configuration (
cat /etc/audit/auditd.conf). - System metrics for sparklines (CPU/RAM/disk/network averages — sampled briefly).
3. What We Will Never Do
- We never modify your system (no
chmod, no file edits, no package installs). - We never access systems you have not explicitly registered with us.
- We never execute exploit code, payloads, or tools intended to bypass security controls.
- We never download files from your server to ours (only the small text output of read commands).
- We never store your data outside our infrastructure unless you explicitly enable the Backup add-on (which writes to a cloud storage provider you connect).
4. Credential Storage
- SSH private keys are encrypted at rest using AES-256-GCM.
- The data encryption key is wrapped with an envelope key managed by AWS KMS.
- Decryption happens only at connection time, in memory, in the worker process.
- No engineer can read SSH credentials in plaintext through normal database access.
5. Asset Load
SecureLuna is designed to put minimal load on your server. Concurrency, jitter, and short timeouts ensure that scheduled runs do not impact production workloads. We sample metrics briefly (sub-second snapshots) rather than running long-lived agents.
6. Permission Model (within SecureLuna)
- Each customer is a tenant. Data is partitioned by tenant.
- Users in a tenant share access to that tenant's assets.
- Asset delegation lets you grant a specific external user access to a single asset with one of three permission levels: VIEW (read-only), SCAN (read + run checks), MANAGE (read + run + edit settings).
- Asset deletion and re-delegation are restricted to the owner tenant.
- SecureLuna operations team has super-admin access for support purposes; all such access is logged in the audit trail.
7. Revoking Access
You can revoke SecureLuna's access to your server at any time by removing our public key from ~/.ssh/authorized_keys. We will detect the connection failure on the next scheduled run and mark the asset as "connection failed" in your dashboard.
8. Reporting a Security Concern
If you discover a vulnerability in SecureLuna or have a security concern, please email wndudgns2001@gmail.com. We will acknowledge within 48 hours.
한국어 요약
- SecureLuna 가 발급한 공개키를 고객이 본인 서버에 설치하면, 매일 SSH 로 접속해 읽기 전용 명령만 실행합니다.
- 읽는 정보: sudoers·패스워드정책·SSH 설정·방화벽·감사 설정·시스템 메트릭. 산업 표준 체크리스트 항목 평가에 필요한 것만.
- 고객 시스템을 변경하지 않으며, 등록하지 않은 시스템에는 접근하지 않습니다. 익스플로잇·페이로드 실행 없음.
- SSH 개인키는 AES-256-GCM + KMS 봉투키로 암호화 저장. 워커 프로세스에서 메모리상으로만 복호화.
- 고객은 언제든 본인 서버의 authorized_keys 에서 SecureLuna 공개키를 제거해 접근 차단 가능.
- 모든 운영팀(슈퍼관리자) 행위는 감사 로그에 기록됩니다.