Ai đang nhận email cảnh báo của website bạn, và địa chỉ đó còn sống không? Sáu thói quen vận hành quyết định bảo mật website WordPress, kèm bảng tự kiểm 8 câu.
Trả lời ngắn
Phần lớn sự cố bảo mật website doanh nghiệp không bắt đầu từ một cuộc tấn công tinh vi, mà từ một địa chỉ email. Website vẫn gửi cảnh báo đều đặn, nhưng gửi tới hộp thư của một nhân viên đã nghỉ, hoặc tới địa chỉ mặc định do bên làm web điền từ ngày bàn giao. Không ai đọc, nên không ai biết. Sáu thói quen vận hành dưới đây — bắt đầu bằng việc kiểm địa chỉ nhận cảnh báo — quyết định phần lớn mức an toàn của một website WordPress.
Mục lục
Câu hỏi đầu tiên: ai đang nhận email cảnh báo?
Hãy thử trả lời trong mười giây: email cảnh báo của website công ty bạn đang gửi về địa chỉ nào?
Nếu bạn phải nghĩ, hoặc phải hỏi lại người khác, thì đó đã là câu trả lời. Và nó là câu trả lời quan trọng hơn mọi thứ khác trong bài này.
Một website WordPress đang chạy bình thường vẫn nói chuyện với chủ của nó gần như mỗi tuần: có bản cập nhật mới, có bình luận chờ duyệt, có người vừa được cấp quyền, có lỗi nghiêm trọng vừa xảy ra, có báo cáo quét bảo mật. Tất cả đi bằng email. Nếu địa chỉ nhận không còn ai mở, website vẫn nói — chỉ là nói vào chỗ không người.
Trên các site chúng tôi đang theo dõi, đây là lỗi vận hành xuất hiện nhiều nhất và cũng vô hình nhất. Nó không làm trang chậm đi, không làm mất đơn hàng ngay hôm sau, không có dấu hiệu nào trên màn hình. Nó chỉ lặng lẽ cắt đứt sợi dây duy nhất giữa website và người chịu trách nhiệm.
Không phải một địa chỉ, mà là ba
Chỗ này khiến rất nhiều người sửa nhầm. Trong một website WordPress điển hình có ít nhất ba ô email khác nhau, nằm ở ba nơi khác nhau, và sửa ô này không đổi ô kia:
- Địa chỉ email quản trị của site — trong Cài đặt, mục Tổng quan. Đây là nơi nhận thông báo cập nhật, lỗi nghiêm trọng, chế độ khôi phục.
- Email của từng tài khoản người dùng — trong hồ sơ người dùng. Đây là địa chỉ dùng để đăng nhập và đặt lại mật khẩu, hoàn toàn tách biệt với ô số 1.
- Ô người nhận của plugin bảo mật — plugin quét mã độc thường có danh sách người nhận báo cáo riêng, không dùng lại ô số 1.
Tài liệu chính thức của WordPress nói rõ địa chỉ email quản trị khác với địa chỉ email gắn vào tài khoản người dùng, và đổi ô này không đổi địa chỉ dùng để đăng nhập (Settings General screen — WordPress.org). Trong thực tế, một doanh nghiệp đổi mỗi ô số 1 rồi yên tâm, trong khi báo cáo quét bảo mật vẫn tiếp tục chảy về hộp thư cũ ở ô số 3.
Cái bẫy "đang chờ xác nhận"
Đây là chi tiết mà người làm vận hành gặp thường xuyên còn người dùng bình thường gần như không biết.
Khi bạn đổi địa chỉ email quản trị rồi bấm Lưu, WordPress không áp dụng ngay. Nó gửi một thư xác nhận tới địa chỉ mới, và địa chỉ mới chỉ có hiệu lực khi ai đó bấm vào liên kết trong thư đó. Từ lúc bấm Lưu tới lúc bấm liên kết, địa chỉ cũ vẫn là địa chỉ đang hoạt động. Màn hình có hiện một dòng thông báo nhỏ "đang chờ xác nhận", nhưng dòng đó rất dễ bị lướt qua.
Hệ quả rất đời thường: người quản lý đổi email cảnh báo sang địa chỉ của mình, nhìn thấy ô đã hiện đúng chữ mình vừa gõ, đóng trình duyệt và tin rằng xong. Thư xác nhận thì rơi vào hộp thư rác, hoặc chính website không gửi được. Nhiều tuần sau, mọi cảnh báo vẫn về địa chỉ cũ.
Cách kiểm trong ba mươi giây: sau khi bấm Lưu, mở đúng hộp thư của địa chỉ mới, tìm thư xác nhận, bấm liên kết, rồi quay lại màn hình cài đặt xem dòng "đang chờ xác nhận" đã biến mất chưa. Chỉ khi dòng đó biến mất mới coi là đã đổi.
Địa chỉ còn sống chưa chắc đã nghe được
Có một tầng lỗi nữa nằm dưới. Địa chỉ nhận cảnh báo có thể vẫn tồn tại, nhưng thư từ website không tới được nó.
Trên các site chúng tôi đang theo dõi, có trường hợp thư hệ thống gửi tới một địa chỉ đã ngừng nhận: máy chủ gửi thử lại nhiều lần trong nhiều ngày rồi mới trả về một thư báo lỗi. Thư báo lỗi đó lại rơi vào một hộp thư không ai mở. Kết quả cuối cùng là toàn bộ cảnh báo bảo mật của website coi như không tồn tại — không phải vì bị chặn, mà vì không còn ai nghe được tiếng chuông.
Nguyên nhân kỹ thuật phổ biến: website gửi thư bằng chức năng gửi thư mặc định của máy chủ web, nên thư mang tên miền công ty nhưng lại xuất phát từ một máy chủ không nằm trong danh sách được phép gửi thư của tên miền đó. Hộp thư nhận thấy chữ ký không khớp và đẩy thẳng vào thư rác. Website "có gửi", hộp thư "có nhận", mà người thì không bao giờ thấy.
Nếu bạn nghi ngờ tên miền công ty đang có vấn đề về thư, phần tự kiểm trong bài Email công ty không nhận được thư làm được trong ba phút và dùng chung cho cả trường hợp này.
Cảnh báo tồn đọng: vì sao "chưa sao cả" là cảm giác sai
Giả sử email cảnh báo đã về đúng người. Vấn đề tiếp theo là gì xảy ra sau khi người đó mở thư.
Trên các site chúng tôi đang theo dõi, có một site doanh nghiệp giữ nguyên mức tám đến mười cảnh báo tồn đọng suốt nhiều tuần liền, từ cuối tháng 8 sang giữa tháng 9 năm nay. Con số gần như không nhúc nhích. Báo cáo bảo mật vẫn gửi đều đặn hằng tuần, đúng giờ, không thiếu tuần nào.
Đây là hình ảnh điển hình hơn người ta tưởng. Đặt cạnh nhau các site trong cùng danh mục theo dõi, khác biệt lớn nhất không nằm ở phần mềm hay nhà cung cấp hosting, mà nằm ở chỗ có người đọc báo cáo hay không. Site nào có người mở ra và xử lý thì số cảnh báo giảm dần theo tuần. Site nào không thì con số đứng yên, tháng này qua tháng khác.
Vì sao người ta để yên? Vì cảnh báo bảo mật có hai đặc tính rất dễ gây nhờn:
- Nó không tự biến mất. Một cảnh báo về plugin cũ sẽ nằm đó tuần này, tuần sau, tháng sau, y nguyên như vậy.
- Nó hiếm khi gây sự cố ngay. Một plugin chưa vá có thể nằm im rất lâu trước khi bị ai đó dùng tới.
Hai điều đó cộng lại tạo ra một kết luận sai rất tự nhiên: "mấy tuần rồi vẫn thấy có cảnh báo mà có sao đâu, chắc không quan trọng". Nhưng cảnh báo không phải dự báo thời tiết cho tuần này. Nó là bản kê những cánh cửa đang không khoá. Cửa không khoá suốt ba tháng mà nhà không mất gì không chứng minh cửa đó an toàn — nó chỉ chứng minh chưa có ai thử mở.
Cách chữa không nằm ở công cụ mà nằm ở thói quen. Trong kinh nghiệm vận hành của ê-kíp Creps, thứ tạo khác biệt là một quy ước rất nhỏ: báo cáo bảo mật hằng tuần phải có một người tên tuổi cụ thể mở ra, và số cảnh báo tồn đọng phải được ghi lại. Chỉ cần ghi con số theo tuần, xu hướng tăng hay giảm sẽ tự nói. Một danh sách không ai đếm là một danh sách sẽ dài ra.
Plugin và giao diện: cập nhật, và những plugin đã bị bỏ hoang
Phần lớn cảnh báo trong các báo cáo nói trên thuộc về plugin và giao diện. Tài liệu bảo mật chính thức của WordPress đặt việc cập nhật ở ngay đầu danh sách các biện pháp cần làm (Hardening WordPress), và đó cũng là việc dễ làm nhất trong bài này.
Ba điều ít được nói tới:
Một, "tắt" không phải là "gỡ". Một plugin bị tắt vẫn nằm nguyên trên máy chủ. Tệp của nó vẫn ở đó, vẫn có thể bị gọi tới trực tiếp. Nếu một plugin không dùng nữa, việc đúng là gỡ hẳn, không phải để nó ngủ đông. Trong nghề, tình huống hay gặp là site bàn giao xong còn tồn năm, bảy plugin bị tắt từ thời dựng thử — không ai dám xoá vì "sợ hỏng", và cũng không ai cập nhật vì "có dùng đâu".
Hai, plugin bỏ hoang nguy hiểm hơn plugin cũ. Plugin cũ thì còn có bản vá để cập nhật. Plugin bỏ hoang thì tác giả đã ngừng phát triển, không còn ai vá nữa. Trang của mỗi plugin trên kho WordPress.org đều hiển thị lần cập nhật gần nhất và phiên bản WordPress đã được thử nghiệm cùng. Hai dòng đó là cách kiểm nhanh nhất: cập nhật gần nhất cách đây đã lâu, hoặc kho ghi rõ plugin chưa được thử với các bản WordPress gần đây, thì nên coi là hàng cần thay thế chứ không phải hàng cần chờ.
Ba, giao diện cũng là phần mềm. Giao diện ít được để ý hơn plugin vì nó "chỉ là cái mặt ngoài", nhưng một giao diện tự viết rồi bỏ đó nhiều năm cũng cũ đi đúng như plugin. Nếu website của bạn do một bên làm rồi ngừng liên lạc, đây là chỗ nên hỏi trước.
Về nhịp, kinh nghiệm vận hành của chúng tôi là một khung giờ cố định trong tuần, làm cập nhật trước, không làm vào chiều thứ Sáu. Không phải vì thứ Sáu xui, mà vì nếu cập nhật làm hỏng gì đó thì bạn cần người còn ngồi ở bàn để xử lý, chứ không phải phát hiện vào sáng thứ Hai qua điện thoại của khách.
Tài khoản quản trị: người nghỉ việc vẫn còn chìa khoá
Danh sách người dùng của một website doanh nghiệp năm tuổi thường dài hơn số người thực sự đang làm việc ở đó.
Có bạn thực tập đã nghỉ từ hai năm trước. Có bên chạy quảng cáo từng xin quyền để gắn mã theo dõi. Có một tài khoản tên admin2 không ai nhớ của ai. Và thường có ít nhất một tài khoản mang tên đơn vị làm website ngày xưa.
Ba việc cần làm, theo thứ tự:
Rà theo quyền, không rà theo tên. Điều cần đếm không phải "có bao nhiêu người" mà "có bao nhiêu tài khoản quyền quản trị". Con số này nên nhỏ tới mức bạn đọc tên từng người ra được. Ai chỉ viết bài thì để quyền viết bài, không cần quyền quản trị.
Khi có người nghỉ, thu đủ chìa khoá. Xoá tài khoản WordPress chỉ là một phần. Người làm website thường còn nắm thêm: tài khoản quản trị hosting, tài khoản tên miền, quyền truy cập tệp máy chủ, và các mật khẩu ứng dụng mà WordPress cấp cho công cụ bên ngoài kết nối vào site. Một tài khoản đã bị khoá nhưng mật khẩu ứng dụng còn sống thì cánh cửa vẫn mở. Thu chìa khoá là thu cả chùm.
Xoá người, đừng xoá bài. Khi xoá một tài khoản có nội dung, WordPress sẽ hỏi bạn muốn xoá toàn bộ nội dung hay chuyển nội dung cho người khác. Bấm nhầm phương án đầu là mất trắng bài viết của người đó, và đây là tai nạn xảy ra thật. Luôn chọn chuyển nội dung sang một tài khoản còn hoạt động.
Cuối cùng là hai việc nhỏ, làm một lần dùng lâu: bật xác thực hai bước cho mọi tài khoản quyền quản trị, và bỏ thói quen dùng chung một tài khoản cho nhiều người. Tài khoản dùng chung phá hỏng thứ quan trọng nhất khi có sự cố: khả năng biết ai đã làm gì. Nếu bạn đang cân nhắc tự vận hành hay thuê ngoài, bài Doanh nghiệp nhỏ có nên tự làm website bàn kỹ hơn về phần chi phí thời gian của những việc này.
Sao lưu chưa từng thử khôi phục thì chưa tính là sao lưu
Gần như doanh nghiệp nào cũng trả lời "có, bên hosting sao lưu tự động". Câu hỏi thứ hai mới là câu hỏi thật: bạn đã khôi phục thử lần nào chưa?
Tài liệu chính thức của WordPress nói rõ một bản sao lưu đầy đủ gồm hai phần: cơ sở dữ liệu và tệp, và cần cả hai mới khôi phục được một site thông thường (Backups — WordPress Advanced Administration). Rất nhiều bản sao lưu mà chúng tôi nhận bàn giao chỉ có một trong hai: có cơ sở dữ liệu mà thiếu thư mục ảnh, hoặc có tệp mà không có cơ sở dữ liệu. Chủ site không biết, vì chưa ai mở gói sao lưu đó ra bao giờ.
Ba câu hỏi để biết bản sao lưu của bạn có thật hay không:
| Câu hỏi |
Vì sao quan trọng |
| Bản sao lưu gồm cả cơ sở dữ liệu lẫn thư mục tệp? |
Thiếu một trong hai thì khôi phục ra một site trống hoặc một site mất toàn bộ ảnh |
| Bản sao lưu để ở đâu? |
Nếu để cùng trong tài khoản hosting đang chạy site, thì một lần tài khoản bị khoá hoặc bị chiếm là mất cả hai |
| Lần gần nhất khôi phục thử là khi nào? |
Bản sao lưu chưa từng mở là một lời hứa, không phải một phương án |
Chi tiết chỉ người làm nghề mới gặp: khôi phục một bản sao lưu WordPress sang tên miền thử nghiệm không phải là chuyện đổi vài dòng địa chỉ. Địa chỉ website nằm rải rác bên trong cơ sở dữ liệu, trong đó có những ô lưu dưới dạng chuỗi có kèm độ dài ký tự ghi sẵn. Nếu bạn mở tệp cơ sở dữ liệu ra rồi thay tên miền cũ bằng tên miền mới bằng thao tác tìm-và-thay thông thường, độ dài ghi sẵn sẽ không còn khớp với chuỗi mới, và những ô đó hỏng im lặng — thường biểu hiện thành mất toàn bộ tuỳ chỉnh giao diện hoặc mất cấu hình của vài plugin. Việc đúng là dùng công cụ thay thế hiểu được định dạng này. Đây chính là lý do một buổi khôi phục thử có giá trị: nó buộc bạn gặp những cái bẫy như vậy vào lúc không có gì bị mất, thay vì vào lúc đang cháy.
Nhịp hợp lý cho một website doanh nghiệp nhỏ: sao lưu tự động hằng ngày, giữ một bản ở nơi khác với hosting, và khôi phục thử mỗi quý một lần lên tên miền thử nghiệm. Buổi khôi phục thử mất khoảng một giờ và là bài kiểm tra trung thực nhất cho toàn bộ phần này.
Tên miền và chứng chỉ bảo mật hết hạn
Hai thứ này không phải lỗi bảo mật theo nghĩa kỹ thuật, nhưng nằm chung một họ với những thứ bên trên: chúng hỏng vì không ai theo dõi ngày hết hạn, và chúng cũng báo bằng email.
Tên miền hết hạn là sự cố có đồng hồ đếm ngược. Website tắt, email tắt cùng lúc, và sau một số ngày nhất định thì việc lấy lại không còn nằm trong tay bạn nữa. Mốc thời gian cụ thể cho tên miền .vn và tên miền quốc tế khác nhau, chúng tôi đã viết riêng trong bài Tên miền hết hạn có lấy lại được không. Việc cần làm ngay hôm nay chỉ có hai: kiểm xem tên miền đang đứng tên ai, và đặt nhắc hạn ở một chỗ không phụ thuộc vào hộp thư của một cá nhân.
Chứng chỉ bảo mật hết hạn thì ồn ào hơn: trình duyệt của khách hiện cảnh báo toàn màn hình trước khi vào được trang. Về mặt kỹ thuật đây là chuyện nhỏ và thường sửa trong ít phút, nhưng mỗi giờ để yên là mỗi giờ khách nhìn thấy website công ty bị trình duyệt gắn nhãn không an toàn. Phần lớn chứng chỉ ngày nay tự động gia hạn — điều cần kiểm là cơ chế tự động đó có đang chạy không, và cảnh báo khi nó thất bại gửi về đâu. Lại là câu hỏi đầu bài.
Dấu hiệu site đã bị lợi dụng mà chủ không biết
Một website bị lợi dụng hiếm khi treo biển. Kẻ chiếm được quyền thường muốn site tiếp tục chạy bình thường càng lâu càng tốt. Ba dấu hiệu dưới đây là thứ chủ site tự quan sát được:
- Mở từ kết quả tìm kiếm thì bị đẩy sang trang lạ. Đây là dấu hiệu hay gặp nhất và cũng hay bị bỏ sót nhất, vì mã chèn vào thường chỉ kích hoạt với người đến từ công cụ tìm kiếm trên điện thoại, và cố tình không kích hoạt với người đang đăng nhập quản trị. Nghĩa là chủ site gõ thẳng tên miền vào trình duyệt thì thấy mọi thứ bình thường, còn khách thì không. Chúng tôi mô tả kỹ dạng sự cố này trong bài Website doanh nghiệp bỗng chuyển hướng sang trang cờ bạc.
- Kết quả tìm kiếm hiện ra những trang bạn chưa từng tạo. Tìm tên miền công ty trên Google và lướt vài trang kết quả. Nếu thấy tiêu đề lạ, chữ lạ, hoặc nội dung không liên quan gì tới ngành nghề của bạn, thì có ai đó đang đăng nội dung trên website của bạn.
- Thư gửi từ website vào thẳng hộp thư rác của người nhận. Ngoài nguyên nhân cấu hình thư, đây còn có thể là hệ quả của việc máy chủ đã bị dùng để phát tán thư rác nên bị các dịch vụ thư đưa vào danh sách xấu.
Cách kiểm nhanh nhất cho dấu hiệu thứ nhất: lấy điện thoại, mở cửa sổ ẩn danh, tìm tên công ty trên Google rồi bấm vào kết quả — đừng gõ thẳng tên miền. Nếu trang mở ra không phải trang của bạn, bạn vừa nhìn thấy đúng thứ khách hàng đang nhìn thấy.
Bảng tự kiểm 8 câu trong 5 phút
Trả lời có hoặc không. Câu nào trả lời "không" thì cột bên phải là việc cần làm.
| # |
Câu hỏi |
Nếu trả lời "không" |
| 1 |
Bạn nói ngay được email cảnh báo của website đang gửi về địa chỉ nào? |
Mở Cài đặt → Tổng quan, đọc ô email quản trị; kiểm thêm ô người nhận trong plugin bảo mật |
| 2 |
Địa chỉ đó thuộc về một người đang làm việc và có mở hộp thư hằng tuần? |
Đổi sang địa chỉ đang dùng, và bấm liên kết xác nhận gửi tới địa chỉ mới cho tới khi dòng "đang chờ xác nhận" biến mất |
| 3 |
Bạn nhận được báo cáo bảo mật trong bảy ngày gần nhất? |
Kiểm hộp thư rác trước; nếu không có, khả năng cao website không gửi thư được — xem phần tự kiểm thư |
| 4 |
Số cảnh báo tồn đọng hiện tại đang giảm so với tháng trước? |
Giao cho một người cụ thể mở báo cáo hằng tuần và ghi lại con số |
| 5 |
Mọi plugin và giao diện đang ở bản mới nhất, không còn plugin tắt mà chưa gỡ? |
Đặt một khung giờ cố định trong tuần để cập nhật; gỡ hẳn plugin không dùng |
| 6 |
Bạn đọc được tên từng người trong danh sách tài khoản quyền quản trị? |
Rà danh sách người dùng, hạ quyền hoặc xoá tài khoản không còn chủ, bật xác thực hai bước |
| 7 |
Bạn đã khôi phục thử bản sao lưu ít nhất một lần? |
Đặt lịch một buổi khôi phục thử lên tên miền thử nghiệm trong quý này |
| 8 |
Bạn biết tên miền hết hạn ngày nào và nhắc hạn nằm ở đâu? |
Kiểm ngày hết hạn, đặt nhắc ở nơi không phụ thuộc hộp thư cá nhân |
Bảy trên tám câu trả lời "có" là một website đang được vận hành tử tế. Dưới bốn câu thì vấn đề không nằm ở phần mềm, mà ở chỗ chưa có ai được giao việc này.
Việc nào tự làm được, việc nào nên nhờ người
Tự làm được, không cần biết kỹ thuật: kiểm và sửa địa chỉ nhận cảnh báo (câu 1, 2), đọc báo cáo hằng tuần và ghi số (câu 4), rà danh sách tài khoản quản trị (câu 6), kiểm ngày hết hạn tên miền (câu 8), và bài kiểm điện thoại ở phần dấu hiệu. Năm việc này chiếm phần lớn giá trị của cả bài và không việc nào cần chạm vào mã nguồn.
Nên nhờ người có nghề: cập nhật hàng loạt trên site đang chạy đơn hàng, khôi phục thử bản sao lưu, và mọi việc sau khi đã phát hiện dấu hiệu bị lợi dụng. Riêng trường hợp cuối, thứ tự xử lý quan trọng hơn tốc độ: dọn mã lạ mà chưa tìm ra đường vào thì vài ngày sau nó quay lại y nguyên.
Creps đang vận hành và theo dõi bảo mật cho website của nhiều doanh nghiệp, với báo cáo gửi hằng tuần và một người chịu trách nhiệm đọc báo cáo đó. Nếu bạn vừa nhận ra mình không trả lời được câu hỏi đầu bài, xem thêm dịch vụ công nghệ của Creps hoặc liên hệ với chúng tôi để được rà soát website hiện tại.
Câu hỏi thường gặp
Website nhỏ, ít khách truy cập thì có cần lo bảo mật không?
Phần lớn sự cố trên website doanh nghiệp nhỏ không đến từ việc ai đó nhắm vào bạn, mà từ các công cụ dò tự động quét hàng loạt địa chỉ và thử những lỗ hổng đã công bố. Chúng không phân biệt website lớn hay nhỏ, chỉ phân biệt đã vá hay chưa vá. Đó là lý do việc cần làm không phải là "phòng thủ mạnh", mà là "đừng để cửa mở lâu".
Cài plugin bảo mật là đủ chưa?
Plugin bảo mật làm tốt việc phát hiện và báo cáo, nhưng nó chỉ báo — nó không thay bạn quyết định. Một site có plugin bảo mật xịn mà không ai đọc báo cáo thì an toàn ngang với site không cài gì, chỉ khác là có thêm một chồng email chưa mở. Giá trị của plugin phụ thuộc hoàn toàn vào thói quen vận hành quanh nó.
Cập nhật plugin WordPress có làm hỏng website không?
Có khả năng, và đó là lý do người ta ngại. Cách giảm rủi ro: sao lưu trước khi cập nhật, cập nhật vào khung giờ vắng khách và có người trực, cập nhật từng nhóm nhỏ thay vì bấm cập nhật tất cả cùng lúc để biết cái nào gây lỗi. Nhưng cần so sánh đúng: rủi ro của việc cập nhật là một lỗi hiện ra ngay và sửa được; rủi ro của việc không cập nhật là một lỗ hổng nằm im không ai thấy.
Website bị hack phải làm sao, có nên xoá site làm lại từ đầu không?
Không nên xoá ngay. Ba việc trước tiên: đổi toàn bộ mật khẩu quản trị và hosting, sao lưu nguyên trạng site đang bị lỗi để còn tìm nguyên nhân, rồi mới dọn. Xoá sạch làm lại mà chưa biết kẻ kia vào bằng đường nào thì site mới thường bị lại bằng đúng đường cũ — nhất là khi nguyên nhân là một tài khoản bị lộ chứ không phải một plugin có lỗ hổng.
Bao lâu nên rà soát bảo mật website một lần?
Trong kinh nghiệm vận hành của ê-kíp Creps, nhịp hợp lý cho một website doanh nghiệp nhỏ là: đọc báo cáo hằng tuần (mười phút), cập nhật plugin và giao diện hằng tuần hoặc hai tuần một lần, rà danh sách tài khoản quản trị mỗi quý, và khôi phục thử bản sao lưu mỗi quý. Điều quan trọng hơn con số là việc mỗi nhịp đó có tên một người cụ thể chịu trách nhiệm.