Triển khai an toàn Umami analytics với Docker và PostgreSQL

Một hướng dẫn kỹ thuật gần đây được công bố vào ngày 18 tháng 10 năm 2026, phác thảo các bước cụ thể cần thiết để tự host phiên bản Umami analytics 3.4.0 sử dụng Docker và PostgreSQL. Bài viết nhấn mạnh các thực hành cấu hình bảo mật, đặc biệt là về liên kết mạng và xác thực ban đầu, nhằm ngăn chặn truy cập trái phép trong quá trình thiết lập.

Chuyện gì đã xảy ra

Hướng dẫn cung cấp một quy trình chi tiết để triển khai Umami, một giải pháp thay thế Google Analytics tập trung vào quyền riêng tư, trong môi trường container hóa. Nó chỉ định sử dụng image ghcr.io/umami-software/umami:3.4.0 cùng với container cơ sở dữ liệu postgres:15.19-alpine. Trọng tâm chính của các hướng dẫn là việc sửa đổi cấu hình Docker Compose mặc định để tăng cường bảo mật ngay khi triển khai.

Tác giả làm nổi bật một rủi ro bảo mật nghiêm trọng trong cấu hình mặc định từ upstream, vốn liên kết cổng ứng dụng với tất cả các giao diện mạng. Vì các cổng được Docker công bố có thể bỏ qua tường lửa ở cấp độ máy chủ (host-level) như ufw, việc giữ nguyên các cài đặt mặc định có thể cho phép các tác nhân bên ngoài tiếp cận ứng dụng trước khi quản trị viên kịp bảo vệ nó. Hướng dẫn khuyến nghị liên kết cổng cụ thể với 127.0.0.1, đảm bảo rằng chỉ các tiến trình cục bộ, chẳng hạn như reverse proxy, mới có thể giao tiếp với instance Umami.

Một phần quan trọng khác của hướng dẫn đề cập đến thông tin đăng nhập mặc định. Umami khởi tạo với sự kết hợp tên người dùng và mật khẩu tiêu chuẩn là admin và umami. Các hướng dẫn nhấn mạnh rằng quản trị viên phải thay đổi mật khẩu này ngay sau lần đăng nhập đầu tiên. Nếu cổng bị lộ ra internet công cộng trước khi thay đổi này diễn ra, bất kỳ người dùng nào phát hiện ra dịch vụ đều có thể đăng nhập với tư cách quản trị viên và xâm phạm instance.

Chi tiết chính

• Umami phiên bản 3.4.0 không hỗ trợ MySQL; PostgreSQL là engine cơ sở dữ liệu bắt buộc.
• Thông tin đăng nhập quản trị mặc định là tên người dùng admin và mật khẩu umami.
• Liên kết cổng Docker với 127.0.0.1:3000 ngăn chặn truy cập mạng bên ngoài vào cổng ứng dụng thô.
• Các bí mật (secrets) như POSTGRES_PASSWORD, APP_SECRET và TWO_FACTOR_ENCRYPTION_KEY nên được lưu trữ trong một tệp .env được bảo vệ.
• Việc thay đổi mật khẩu PostgreSQL trong các biến môi trường sau khi tạo cơ sở dữ liệu ban đầu sẽ gây ra lỗi xác thực trừ khi mật khẩu người dùng cơ sở dữ liệu cũng được cập nhật thủ công.
• Ứng dụng bao gồm một bộ lọc phát hiện bot âm thầm loại bỏ các yêu cầu từ trình duyệt headless, điều này có thể gây nhầm lẫn cho các nhà phát triển trong quá trình kiểm thử.

Bối cảnh

Việc tự host phần mềm phân tích mang lại cho các tổ chức quyền kiểm soát dữ liệu của họ, nhưng đồng thời chuyển hoàn toàn trách nhiệm bảo mật sang đội ngũ IT nội bộ. Không giống như các dịch vụ được quản lý nơi nhà cung cấp xử lý việc vá lỗi và kiểm soát truy cập, các instance tự host đòi hỏi cấu hình cẩn thận các ranh giới mạng và cơ chế xác thực. Docker đơn giản hóa việc triển khai các ứng dụng phức tạp như Umami bằng cách đóng gói ứng dụng và các phụ thuộc của nó vào các container, nhưng nó giới thiệu các hành vi mạng cụ thể mà quản trị viên phải hiểu rõ.

Một quan niệm sai lầm phổ biến là cho rằng tường lửa ở cấp độ máy chủ tự động bảo vệ các container Docker. Trong nhiều cấu hình mặc định, Docker quản lý các quy tắc iptables riêng, có thể ghi đè lên các cài đặt tường lửa do người dùng định nghĩa như ufw. Điều này có nghĩa là nếu một container công khai một cổng cho máy chủ, nó có thể truy cập được từ mạng rộng hơn ngay cả khi tường lửa máy chủ dường như chặn lưu lượng đó. Hiểu được tương tác này là rất quan trọng để bảo mật bất kỳ ứng dụng web tự host nào.

Tại sao điều này quan trọng

Đối với các nhóm vận hành phần mềm riêng, sự khác biệt giữa một triển khai an toàn và một triển khai dễ bị tổn thương thường nằm ở những chi tiết cấu hình nhỏ. Khuyến nghị liên kết với localhost là một chiến lược phòng thủ theo chiều sâu (defense-in-depth) cơ bản. Nó đảm bảo rằng ứng dụng không bị phơi bày trực tiếp ra internet, buộc mọi lưu lượng đi qua một reverse proxy như Caddy hoặc Nginx. Thiết lập này cho phép proxy xử lý việc kết thúc TLS và các tiêu đề bảo mật bổ sung, trong khi bản thân ứng dụng vẫn được cô lập trên giao diện loopback cục bộ.

Vấn đề với thông tin đăng nhập mặc định là một thách thức dai dẳng khác trong các môi trường tự host. Nhiều dự án mã nguồn mở sử dụng mật khẩu mặc định đơn giản để tạo điều kiện thuận lợi cho việc thiết lập và kiểm thử ban đầu. Tuy nhiên, nếu các giá trị mặc định này không được thay đổi ngay lập tức, chúng trở thành một điểm xâm nhập nổi tiếng cho kẻ tấn công. Tự động hóa quy trình tạo bí mật, như được gợi ý trong hướng dẫn sử dụng các công cụ như openssl, giảm thiểu rủi ro do lỗi con người và đảm bảo rằng mỗi triển khai bắt đầu với các thông tin đăng nhập độc nhất và mạnh mẽ.

Ngoài ra, lưu ý của hướng dẫn về bộ lọc bot nhấn mạnh tầm quan trọng của việc hiểu logic ứng dụng trong quá trình khắc phục sự cố. Các nhà phát triển thường kiểm thử các triển khai mới bằng các công cụ tự động hoặc trình duyệt headless, mà Umami nhận diện là bot và bỏ qua. Nếu thiếu kiến thức này, các nhóm có thể dành nhiều thời gian để gỡ lỗi tại sao các script theo dõi của họ dường như thất bại, trong khi thực tế hệ thống đang hoạt động đúng như thiết kế để duy trì chất lượng dữ liệu.

Bạn có thể làm gì

• Tạo các bí mật ngẫu nhiên, mạnh cho POSTGRES_PASSWORD, APP_SECRET và TWO_FACTOR_ENCRYPTION_KEY trước khi khởi động các container.
• Sửa đổi tệp Docker Compose để liên kết cổng Umami với 127.0.0.1 thay vì tất cả các giao diện.
• Triển khai một reverse proxy như Caddy để xử lý các kết nối HTTPS và chuyển tiếp lưu lượng tới instance Umami cục bộ.
• Đăng nhập ngay sau lần khởi động đầu tiên và thay đổi mật khẩu admin mặc định bằng một giá trị mạnh và độc nhất.
• Ghim tag image Docker vào một phiên bản cụ thể như 3.4.0 thay vì sử dụng latest để đảm bảo các nâng cấp dự đoán được.
• Kiểm thử chức năng theo dõi bằng một trình duyệt chuẩn với user agent bình thường để tránh bị bộ lọc phát hiện bot tích hợp chặn lại.