Những tuyên bố có thể kiểm chứng.

Mật khẩu chỉ cần để mở kết nối SSH đầu tiên và cài đặt một người dùng dịch vụ. Nó được truyền dưới dạng xác thực SSH cho kết nối của chúng tôi — không phải làm tham số dòng lệnh hay biến môi trường. Cơ sở dữ liệu của chúng tôi không có trường nào cho nó; nó không đi vào môi trường chạy script và không được ghi vào log (lỗi kết nối chỉ chứa địa chỉ và cổng, không bao giờ có mật khẩu). Trong bộ nhớ, nó được xóa (theo cơ chế best-effort) sau khi dùng — đó là phòng thủ theo lớp, không phải một sự bảo đảm: Go có thể giữ các bản sao của giá trị trên heap cho tới khi thu gom rác.

Lưu ý trung thực: đây vẫn là mật khẩu root trên máy chủ của bạn. Sau khi cài đặt, chúng tôi vô hiệu hóa đăng nhập bằng mật khẩu và đăng nhập root qua SSH, nhưng chúng tôi không đổi chính mật khẩu đó — hãy tự đổi nếu bạn muốn. 'Chúng tôi không lưu nó' là đúng; 'nó không còn là bí mật nữa' thì không.

PasswordAuthentication no, PermitRootLogin no, SSH được chuyển sang cổng không tiêu chuẩn (mặc định 12011), fail2ban được bật (chặn một giờ sau 5 lần thất bại), chỉ đăng nhập bằng khóa. Khóa công khai được kiểm tra chặt chẽ trước khi dùng: các ký tự xuống dòng (nhằm phòng việc chèn thêm khóa lạ vào authorized_keys) và các khóa sai cú pháp đều bị từ chối.

Chống tự khóa mình ra ngoài: cổng 22 không bị đóng cho tới khi nhân hệ điều hành xác nhận (qua ss) rằng cổng SSH mới thực sự đang lắng nghe; cấu hình được kiểm tra bằng sshd -t và quy tắc sudo bằng visudo -cf, cả hai đều được hoàn tác nếu có lỗi.

Bảng điều khiển làm việc không phải với mật khẩu của bạn mà với một khóa riêng (ed25519) do chính nó tạo ra. Phần khóa riêng nằm trong cơ sở dữ liệu, được mã hóa bằng AES-256-GCM. Khóa mã hóa (KEK) được lưu tách khỏi cơ sở dữ liệu — trong một biến môi trường của máy chủ — và ở môi trường production thì bắt buộc phải có (không có giá trị mặc định kém an toàn nào: thiếu KEK thì phân hệ mật mã đơn giản là không khởi động). Chính cơ chế mã hóa này bảo vệ các bí mật nặng ký trong cơ sở dữ liệu — mật khẩu/token/JWT quản trị Marzban, khóa Reality, khóa của nhà cung cấp thanh toán, bộ nhớ đệm thông tin đăng nhập proxy, cấu hình sao lưu.

Mã hóa không chỉ che giấu mà còn xác thực dữ liệu (thẻ xác thực GCM): việc can thiệp vào một trường đã mã hóa sẽ bị phát hiện khi giải mã và bị từ chối. Mỗi trường được mã hóa với một nonce ngẫu nhiên mới; giá trị KEK không bao giờ vào log — chỉ có id ngắn của nó.

Về các token cấp quyền: token đăng ký /sub là một bí mật dạng bearer. Để tra cứu, chúng tôi chỉ lưu SHA-256 của nó, còn bản sao cần để hiển thị lại một liên kết đã cấp thì được giữ dưới dạng bản mã AES-GCM. Các bản ghi văn bản thuần cũ được chuyển sang định dạng mới, theo cơ chế fail-closed, trước khi máy chủ HTTP khởi động. Mã định danh URL của webhook thanh toán được lưu ở dạng rõ nhưng bản thân nó không xác thực một sự kiện: tính xác thực được kiểm chứng riêng bằng chữ ký HMAC.

Khóa chỉ được giải mã trên máy chủ, trong bộ nhớ; các API thông thường không bao giờ trả về nó. Cách duy nhất để lấy nó là một chức năng xuất có chủ đích ('lấy khóa của bạn'), được bảo vệ bằng đăng nhập cộng với một mã email dùng một lần (mã chỉ được lưu dưới dạng băm HMAC, so sánh trong thời gian hằng, TTL 10 phút, 5 lần thử). Vậy nên khóa có thể được lấy một cách chủ đích, nhưng không thể bị 'rò rỉ' qua một yêu cầu thông thường.

Trước khi trạng thái của máy chủ thay đổi và trước bất kỳ thao tác mạng nền nào, các trường chứa khóa quản lý được ghi về 0 một cách đồng bộ. Nếu cơ sở dữ liệu không xác nhận việc xóa, thao tác trả về lỗi và có thể thử lại. Việc xóa vẫn là 'mềm': hàng dữ liệu và các dữ liệu dịch vụ không bí mật vẫn được giữ lại. Điều này không đồng nghĩa với việc xóa vật lý các bản sao lưu đã tạo — vòng đời của chúng do chính sách lưu giữ bản sao lưu chi phối.

Các route đối tác đã kiểm toán cấp quyền theo partner_id, giá trị mà máy chủ suy ra từ token đăng nhập đã ký — không phải từ những gì client gửi trong đường dẫn hay phần thân. Trước khi trả về hay thay đổi bất cứ điều gì, hệ thống kiểm tra lại rằng máy chủ, cụm, inbound, route, người dùng VPN hay khoản thanh toán được yêu cầu thuộc về tài khoản của bạn; các truy vấn cơ sở dữ liệu tương ứng được giới hạn theo partner_id của bạn, và lược đồ (khóa duy nhất kết hợp cùng khóa ngoại kết hợp) từ chối các liên kết chéo giữa các đối tác không hợp lệ. Cách ly được phân lớp: ứng dụng, kiểm tra lại ở tầng usecase, một bộ lọc partner_id, và lược đồ.

Lưu ý trung thực: điều này được kiểm chứng bằng một cuộc kiểm toán mã dọc theo đường đi của yêu cầu, chứ không phải bằng một cuộc kiểm thử xâm nhập công khai — nên SR-16, như những mục còn lại, luôn mở để bị bác bỏ trong bug bounty.

Để cấu hình mọi thứ tự động (cài đặt Xray+Reality, áp dụng cấu hình, đọc chỉ số) bảng điều khiển nắm quyền quản trị đầy đủ trên máy chủ (tương đương root, thông qua một người dùng dịch vụ có sudo không cần mật khẩu). Điều này là cần thiết cho việc quản lý, và chúng tôi KHÔNG gọi nó là 'hạn chế'.

Điều làm giảm rủi ro: các bí mật chỉ được truyền tới máy chủ qua stdin của tiến trình (không phải làm tham số dòng lệnh — chúng không hiện trong danh sách tiến trình); sau lần cài đặt ban đầu, mọi kết nối quản lý đều xác minh khóa host đã ghim của máy chủ — một cú tráo máy chủ 'ở giữa' sẽ bị từ chối. Điều bạn kiểm soát: quyền truy cập dựa trên một khóa mà bạn có thể thu hồi bất cứ lúc nào — bằng cách xóa máy chủ (khóa được ghi về 0) hoặc đơn giản là xóa VPS tại nhà cung cấp của bạn (khi đó mọi thứ biến mất).

Bản thân các tài khoản VPN (VLESS/Reality) được tạo và nằm trong Marzban trên máy chủ chính của bạn. Ở phía trung tâm, chúng tôi chỉ lưu những gì cần để cấp một liên kết đăng ký: một token đăng ký ngẫu nhiên và một ảnh chụp đã mã hóa của thông tin đăng nhập proxy (một bộ nhớ đệm; nguồn dữ liệu gốc là Marzban của bạn). Chúng tôi không có lịch sử lưu lượng, IP hay lượt truy cập của người dùng.

Dưới đây là danh sách trung thực về những nơi mà email của người dùng cuối thực sự đi qua cơ sở dữ liệu trung tâm của chúng tôi: email chứa mã đăng nhập do chúng tôi gửi, nên địa chỉ đi qua hàng đợi gửi của chúng tôi (đối với mọi lần đăng nhập vào gian hàng, kể cả miễn phí); khi thanh toán, email của người mua đến trong webhook thanh toán và vào nhật ký thanh toán; khi liên kết Telegram, email được lưu vào hồ sơ. Đây là những điểm chạm duy nhất — mang tính chức năng và do cần thiết; không điểm nào trong số đó liên quan đến lưu lượng hay hành vi của người dùng.

Chúng tôi chỉ lưu những dữ liệu dịch vụ này trong đúng thời gian cần thiết và xóa tự động: email được loại khỏi hàng đợi gửi ngay sau khi gửi, nội dung của một sự kiện thanh toán sau khi xử lý, và các sự kiện đang chờ thử lại trong một khoảng 90 ngày. Bạn có thể xóa tài khoản của mình cùng với dữ liệu liên quan bằng cách liên hệ bộ phận hỗ trợ (xem rủi ro 7 để biết chi tiết). Chúng tôi công bố điều này một cách cởi mở thay vì che giấu sau những lời lẽ mơ hồ.

Nền tảng CreateYourVPN không nhận hay lưu thông tin về việc bạn hay người dùng của bạn truy cập những trang nào. Lược đồ tiếp nhận chỉ số là đóng: về mặt vật lý nó không có trường nào cho IP, tên miền hay lượt truy cập — chỉ có các giá trị tổng hợp (số người trực tuyến duy nhất, tổng số byte, CPU/RAM/mức tải). Mỗi node xác thực bằng một token HMAC gắn với id của chính nó và chỉ có thể ghi chỉ số cho chính mình. Bộ cân bằng tải trên node (HAProxy) hoạt động như một bộ định tuyến TCP theo SNI và không giải mã lưu lượng. Trên chính máy chủ, các nhật ký hệ thống được giữ không quá khoảng một giờ và không được chuyển tiếp tới syslog.

Ngoài cấp nền tảng, các máy chủ cũng không lưu nhật ký truy cập: việc ghi log truy cập của Xray bị buộc tắt trong mỗi lần đẩy cấu hình (nền tảng đặt log.access thành none), nên proxy biên không ghi lại người dùng kết nối tới những địa chỉ nào. Điều này được thực thi trong mã và đã triển khai ra toàn bộ đội máy chủ.

Để hiểu trang web và bảng điều khiển được sử dụng ra sao, chúng tôi dùng Google Analytics (dải thông báo cookie cảnh báo về việc thu thập cookie và thống kê; chi tiết ở Chính sách quyền riêng tư). Không có trình theo dõi bên thứ ba nào khác: không Sentry, PostHog, Mixpanel hay pixel quảng cáo (đã xác minh bằng cách tìm trong cả hai frontend). Backend hoàn toàn không có telemetry của bên thứ ba. Cửa hàng dành cho người dùng cuối hoàn toàn không có phân tích nào — không GA, không trình theo dõi (có thể kiểm chứng từ mã nguồn của nó).

Lưu ý: GA nhận IP của bạn (ở phía Google) và địa chỉ của các trang bảng điều khiển được xem; URL của bảng điều khiển chỉ chứa mã định danh cụm, không phải email.

Thanh toán và toàn bộ dữ liệu thẻ được xử lý ở phía nhà cung cấp (Tribute / Lemon Squeezy). Chúng tôi chỉ nhận một webhook đã ký (HMAC-SHA256, so sánh trong thời gian hằng, được kiểm chứng trước khi phần thân được phân tích và trước bất kỳ lần ghi cơ sở dữ liệu nào: nếu không biết bí mật, một sự kiện sẽ không qua được khâu xác minh). Chúng tôi không nhận số thẻ đầy đủ (PAN) hay CVV. Việc gửi lại cùng một webhook (nhà cung cấp thử lại) không gây cấp quyền hai lần — các sự kiện được khử trùng lặp.

Lưu ý: nhà cung cấp có thể đưa vào phần thân webhook siêu dữ liệu thẻ (thương hiệu và 4 chữ số cuối) cùng tên và email của người trả tiền. Worker cần phần thân gốc cho tới khi xử lý xong; sau khi xử lý thành công nó bị xóa cùng với gợi ý email. Các sự kiện đang chờ thử lại hoặc chờ xem xét thủ công chỉ giữ phần thân gốc cho tới khi kết thúc cửa sổ lưu giữ (90 ngày không hoạt động), sau đó siêu dữ liệu thẻ và email của người trả tiền sẽ bị xóa tự động. 'Không có số thẻ đầy đủ' là đúng, nhưng đó là đặc tính của các nhà cung cấp (chúng tôi không tự lọc phần thân); 'chúng tôi hoàn toàn không thấy gì về thẻ' thì không.

Email (cần để đăng nhập), thời điểm đăng nhập gần nhất, chế độ giao diện; phục vụ thanh toán — số dư và Telegram (để nạp tiền). IP của đối tác không được lưu trong cơ sở dữ liệu, và chúng tôi không giữ lịch sử nhấp chuột hay thao tác trong bảng điều khiển (ngoài một log truy cập ngắn khi có lỗi).

Tường lửa mặc định chặn kết nối đến. Mở ra ngoài: 443 (VPN, Xray+Reality), SSH trên một cổng không tiêu chuẩn (mặc định 12011), và — trên máy chủ chính — cổng bảng quản trị Marzban, chỉ cho các IP thuộc mặt phẳng điều khiển. Cổng 80 chỉ được mở riêng trong chế độ Let's Encrypt cho HTTP-01. Cổng 22 bị đóng sau khi SSH được chuyển đi.

Các cổng quản lý của node chỉ mở cho IP của máy chủ chính, không mở ra ngoài (nếu ràng buộc này thất bại thì việc cài đặt bị hủy). Nếu tường lửa không được kích hoạt, việc cài đặt thất bại. ICMP echo chỉ bị giới hạn cho IPv4; chúng tôi không hứa máy chủ là 'vô hình', và ICMP của IPv6 được giữ lại để IPv6 hoạt động đúng.

Unattended upgrades tự động cài các bản cập nhật gói bảo mật. Lưu ý: việc khởi động lại tự động bị chủ ý vô hiệu hóa (để một nhân chưa được kiểm chứng không tự khởi động lại) — nghĩa là những bản sửa cần khởi động lại (nhân, đôi khi OpenSSH) chỉ được áp dụng sau một lần khởi động lại thủ công hoặc theo lịch. 'Tự động vá' là đúng với phần không gian người dùng, chứ không đúng với những gì cần khởi động lại.

Chúng tôi KHÔNG tuyên bố máy chủ là 'vô hình' hay 'không thể bị quét'. Cổng 443 mở và đáp lại một kết nối TCP như bất kỳ máy chủ web nào. Đặc tính 'khi kết nối không đúng cách thì nó trông như một website bình thường chẳng liên quan' là do giao thức Reality bên trong Xray cung cấp — một thành phần riêng mà chúng tôi không biến thành một điều tuyệt đối.

Đối tác đăng nhập bằng một mã 6 chữ số dùng một lần gửi tới email. Không có mật khẩu tài khoản. Điều này không áp dụng cho thông tin đăng nhập nội bộ của các thành phần được quản lý, chẳng hạn mật khẩu quản trị Marzban được sinh ra. Các mã được tạo bởi một bộ sinh mật mã; chỉ băm HMAC của chúng được lưu, và việc so sánh diễn ra trong thời gian hằng. Mã dùng một lần: khi thành công nó bị xóa ngay lập tức (không thể phát lại); sau 5 lần thử sai nó bị vô hiệu sớm. Giới hạn tần suất cấp mã được tính theo email, không phải theo IP — không thể lách bằng cách đổi địa chỉ.

Token phiên nằm trong một cookie HttpOnly và Secure (JS không đọc được), được xác minh ở backend (không chỉ ở tầng edge). Hết hạn do không hoạt động và tự động đăng xuất khi bỏ trống được cài đặt ở phía client, không phải ở máy chủ. Token được ký bằng HS256; khi xác minh, chúng tôi từ chối nghiêm ngặt mọi thuật toán khác (kể cả 'none') — cuộc tấn công tráo thuật toán kinh điển không lọt qua. Token của cửa hàng và token của bảng điều khiển đối tác được tách theo đối tượng (audience): về mặt kỹ thuật, một token của người dùng cuối không thể chạm tới API đối tác (và ngược lại). Một đối tác đã bị xóa vẫn bị từ chối ngay cả khi token còn hiệu lực.

Lưu ý: việc thu hồi được thực hiện bằng cách kiểm tra rằng đối tác còn tồn tại ở mỗi yêu cầu, chứ không phải bằng cách vô hiệu hóa chính token; đăng xuất sẽ xóa cookie, nhưng một token đã cấp vẫn hợp lệ về mặt mật mã cho tới khi hết hạn (tối đa một giờ). Hiện chưa có danh sách thu hồi tập trung (một sự đơn giản hóa có chủ ý ở giai đoạn MVP).

Không có token nào trong local storage của trình duyệt (chỉ có các thiết lập giao diện); không có bí mật hay địa chỉ API nào lọt vào gói client. Chỉ máy chủ (Next.js) mới đặt token vào một cookie HttpOnly. Trình duyệt chỉ trao đổi với lõi thông qua máy chủ (Server Actions): frontend không gọi trực tiếp API từ trình duyệt, và CORS không cho phép trình duyệt đọc phản hồi API từ các origin khác.

Làm rõ thay cho một khẳng định tuyệt đối trước đây: bản thân tên miền API là một host công khai — về mặt kỹ thuật bạn có thể mở nó từ trình duyệt, nhưng khi không có phiên thì nó không trả về dữ liệu có quyền nào.

Các tên miền công khai của CreateYourVPN được phục vụ qua HTTPS với HSTS (max-age hai năm, includeSubDomains). Cả frontend web lẫn tên miền API đều gửi một bộ header bảo mật nghiêm ngặt: một Content-Security-Policy hạn chế, X-Content-Type-Options: nosniff, X-Frame-Options, và một Referrer-Policy được khóa chặt (no-referrer trên API; strict-origin-when-cross-origin trên frontend, vốn cũng gửi một Permissions-Policy hạn chế).

Điều này đang chạy trong môi trường sản xuất trên cả hai tên miền và có thể kiểm chứng độc lập — bằng bất kỳ công cụ kiểm tra header HTTP nào hoặc một dịch vụ như SSL Labs.