DR testing – Disaster Recovery Testing

Lần đầu tiên mình nghe về DR test, đúng là từ trước đến nay chưa biết về khái niệm này. Đây là một phần công việc cho việc kiểm toán cuối năm của công ty.

DR testing viết tắt của Disaster Recovery Testing. Dịch ra tiếng việt là thử nghiệm khắc phục thảm họa. Phần này khá rộng đối với cả doanh nghiệp chứ không chỉ riêng trong các phần mềm của công ty.

Trong lĩnh vực phần mềm thì phần này nôm na là test các ứng dụng, server, cơ sở dữ liệu dự phòng xem có hoạt động tốt và đúng như hệ thống prod để chạy không. Việc này đáng lẽ ra là phải làm thường xuyên vì phần mềm và CSDL luôn được nâng cấp, do vậy đối với các phiên bản dự phòng thì luôn phải đảm bảo như trong PROD ít nhất là trước thời điểm sửa đổi.

Hàm tuyến tính và linear regression

Các bài toán có thể giải bằng linear regression là các bài toán có thể biểu diễn bằng một hàm tuyến tính.

Vậy hàm số tuyến tính là hàm số như thế nào? Hàm số tuyến tính là hàm số có dạng là một đường thẳng y=ax+b. Mở rộng ra ta có hệ phương trình tuyến tính là hệ phương trình có các phương trình là phương trình tuyến tính, hay nói cách khác là phương trình tuyến tính có nhiều hơn 1 biến.

Bởi vì nếu chỉ có 1 phương trình tuyến tính nhiều hơn 1 biến thì có vô số nghiệm, cần phần có các điều kiện hoặc nhiều hơn 1 phương trình tuyến tính thì mới có thể giải được.

Quay lại việc giải bài toán bằng LINEAR REGRESSION thì chỉ cần nó là hàm tuyến tính theo trọng số (w).

Khởi động app theo đặc quyền

Chuyện là hôm nay đồng nghiệp mình tiến hành thực hiện một số thao tác cập nhật một số file xml trong ứng dụng nhưng không được. Hệ thống báo không có quyền mặc dù việc này bình thường vẫn có thể làm được. Ứng dụng bên mình code bằng Java chạy trên webserver là tomcat. Qua kiểm tra thì thấy gần đây App Tomcat được khởi động lại bằng quyền root. Bình thường thì việc reset App Tomcat chỉ được thực hiện với quyền bình thường (không phải quyền root).

Lý giải điều này là do việc phân quyền trên Linux. Việc cài đặt hay reset app trên Linux với quyền khác nhau là khác nhau trên Linux. Khi reset bằng quyền root thì với các user khác sẽ gặp một số vấn đề về quyền khi truy cập một số file trên đó. Phần này mình chưa rõ lắm nhưng cần note lại để sau tìm hiểu thêm.

Cách khắc phục thì phải stop app Tomcat bằng quyền root và sau đó start bằng quyền vẫn hay sử dụng.

Nhưng trên window thì theo mình thấy không vấn đề gì cả.

Quản lý tài khoản đặc quyền với CyberArk

Hôm nay đối tác CyberArk giới thiệu và đào tạo công ty mình chuẩn bị sử dụng CyberArk để quản lý tài khoản đặc quyền. Theo mình hiểu CyberArk cung cấp một giải pháp quản lý và bảo mật hạ tầng CNTT của doanh nghiệp nói chung. Bao gồm các thiết bị phần cứng, hạ tầng mạng, các server (vật lý và ảo hóa), các data center, cơ sở dữ liệu…

Trước đây đối với các công ty mà mình từng làm việc quản lý server khá thủ công. Mặc dù một số nơi có sử LDAP để quản trị user nhưng đối với mỗi server thì đều phải tự cài đặt và quản trị riêng cho nó. Đội ngũ phần cứng nắm giữ một user admin có quyền cao nhất và riêng biệt. Sau đó trưởng mỗi server sẽ được cung cấp một user admin cũng có quyền cao nhất sau đó là các nhân viên khác có quyền thấp hơn. Như vậy đối với mỗi server việc quản lý sẽ độc lập, từng người dùng phải server và tài khoản của mình. Như mình một lúc quản lý dưới chục server đã rất hay bị quên và thường xuyên phải dùng chung một mật khẩu duy nhất. Biết là thiếu tính bảo mật nhưng không còn cách nào khác, lưu ra một nơi riêng cũng không an toàn. Lưu trạng thái đăng nhập thì lại càng không an toàn nữa. Nói chung là khá bất cập.

Hơn nữa với việc quản lý cũ việc tra lại lịch sử thao tác tới server là hoàn toàn bất khả thi. Việc truy xuất thời gian đăng nhập đã là khó khăn, việc xem người dùng làm những gì thì hầu như không thể nào biết được.

CyberArk là giải pháp hữu hiệu có thể đáp ứng hầu như hoàn toàn cách quản lý trên. CyberArk được cài đặt trên ít nhất 1 server để có thể quản lý các tài khoản đặc quyền riêng. Mặc dù mới chỉ được giới thiệu và đào tạo nhưng mình có thể thấy được một số ưu nhược điểm như sau:

  • CyberArk được cài đặt trên server riêng và bán licensen theo số lượng user của hệ thống để thực hiện thao các trên các server.
  • Người dùng CyberArk có thể được cung cấp tài khoản riêng biệt hoặc sử dụng LDAP để xác thực như xác thực email, xác thực vào máy tính cá nhân, xác thực wifi công ty…
  • Từ CyberArk người dùng không phải nhớ bất kỳ IP cũng như tài khoản server nào. Tất cả sẽ được hiển thị hết trong danh sách các server được phép sử dụng.
  • CyberArk không chỉ quản trị server mà còn quản trị được nhiều các phần mềm khác nhau. CyberArk có tác dụng như là một server trung gian, phần mềm trung gian. Người dùng qua đó xác thực và sử dụng như trên chính thiết bị của mình.
  • Ví dụ remote hoặc SSH vào server thì nó đứng ở trung gian xác thực mình. Mình chỉ cần bấm vào là remote được luôn, không cần gõ mật khẩu hoặc tài khoản gì cả.
  • Ví dụ connect phần mềm quản trị Database Oracle là Toad. Bình thường máy cá nhân mình phải cài Toad để kết nối tới Oracle. Khi dùng CyberArk thì trên server cài CyberArk cũng phải cài Toad. Khi mình đăng nhập vào CyberArk, tìm đến phần Toad thì mình chỉ cần chọn, CyberArk sẽ tự động mở Toad ở máy mình, xác thực qua đó là mình đã có thể sử dụng được.
  • CyberArk tiến hành quay lại màn hình toàn bộ các thao tác của người dùng tác động lên server. Vì là đi qua nó nên nó bắt được toàn bộ các sự kiện click, các cửa sổ được mở, các lệnh được gõ vào server. Nó lưu lại vừa dưới dạng file text vừa dưới dạng video để người quản trị cao hơn có thể xem lại.
  • Vì nó có thể ghi nhận được các thao tác nên nó hoàn toàn có thể can thiệp được những lệnh, thao tác nguy hiểm hoặc không được phép lên hệ thống. Nó có thể quyết định không thực thi hoặc kết thúc phiên làm việc ngay lập tức.
  • Đối với các server đặc biệt, nó còn có tính năng yêu cầu quyền truy cập để cấp trên có thể phê duyệt thời gian vào để làm việc. Việc này rất tốt để lên kế hoạch bảo trì hoặc nâng cấp hệ thống.
  • Mặc dù test qua nhưng có một số vấn đề mà nó chưa thể xử lý được ngay cần phải check lại:
    — Đối với Linux, công việc thường ngày khi SSH vào hệ thống thì thường xuyên phải thay đổi vai trò lúc thì user thường lúc thì user root. Hiện tại nó không cho phép sự thay đổi này. Nhưng họ nó có 1 add-on cho phép làm việc này nên để nó test trước và thông tin lại.
    — Đối với Window, mỗi user thường tạo ra các schedule thực hiện các công việc khác nhau. Việc đổi pass liên tục sau mỗi phiên sẽ gây các schedule không thực hiện được cũng như những người khác muốn sửa sẽ rất khó khăn. Nó sẽ check lại giải pháp.
    — Đối với cả Linux và Window, nếu người dùng run một bath hoặc crontab, schedule thực thi các lệnh nguy hiểm thì CyberArk cũng không phát hiện và ngăn chặn được. CyberArk chỉ phát hiện được khi người dùng gõ hoặc dùng chuột. Cái này thì là hạn chế, nó không thể có giải pháp được.

Tất nhiên sâu, chi tiết và thực tế thì cần tìm hiểu và sử dụng thêm. Những cái này chỉ mà mới nhận định ban đầu sau một buổi nghe giới thiệu và đào tạo(chưa được thực hành).

Nhìn chung là khá tiên tiến, mặc dù nó lưu vết và quản trị rất khắt khe gây cảm giác khó chịu và luôn bị soi mói thao tác. Nhưng buộc phải chấp nhận thôi nhất là đối với các server product cần phải làm vậy để quy trách nhiệm cũng như đảm bảo an toàn hệ thống. Các công ty vừa và lớn nên mua và sử dụng vì nó cũng nằm một phần trong tiêu chuẩn ISO.

Quản lý phiên bản database với LiquiBase

Việc quản lý phiên bản đối với code đã xuất hiện từ rất lâu và đã có rất nhiều các phần mềm dành cho nó. Theo mình biết và đã từng sử dụng đó là

  • SVN (tiếp cận khá nhiều, coi như đầu tiên, khá cũ và có một số nhược điểm nhưng dễ dùng, phù hợp với các dự án về C#)
  • GIT (cái này khá tiên tiến, mạnh mẽ, càng ngày càng nhiều người dùng, Gitlab, GitHub…)
  • Source Safe (Visual Source Safe) được mua và tiếp tục phát triển bới Microsoft. Cái này mình mới nghe qua chứ chưa dùng bao giờ.

Đó là với code, thế với database thì như thế nào? Trước đây đúng là thuộc dạng 5 mức ngu dốt luôn. Đồng nghiệp hỏi làm mình đứng hình vì còn chưa bao giờ nghĩ đến nó cơ. Tìm hiểu thêm thì biết đúng là nó có tồn tại nhưng còn rất sơ khai. Mặc dù rất quan trọng nhưng lại rất sơ khai do tính đặc thù và khó khăn của nó.

Đại loại là trong quá trình phát triển phần mềm, nhiều phiên bản được nâng cấp và cải thiện, những thay đổi nhỏ thì chỉ cần sửa code nhưng với những thay đổi lớn thì có thể phải sửa cả việc thiết kế cơ sở dữ liệu. Để quản lý việc sửa đổi này thì ta cũng phải có công cụ tương đương như việc quản lý version của code.

Trước đây công ty cũ mình mua phần mềm nước ngoài thì khi nâng cấp nó sẽ gửi cho mình bản code nó đã build. Còn về phần mềm nó sẽ vứt do một loại các kettel Pentaho để chạy theo tuần tự để nâng cấp version cho Database, gọi với cái tên mỹ miều là Migrate dữ liệu.

Tìm hiểu qua thì mình thấy 3 cái tên được nhắc đến nhiều là:

  • SQL Server Data Tools: Cái này của Microsoft, mới nghe qua tên thôi, chắc chỉ support cho SQL Server
  • Flyway: Mới nghe đến tên
  • Liquibase: Thằng này hiện công ty mình đang dùng và được nghe nói đến nhiều nhất. Đang dùng nó để thay đổi với Oracle đi kèm là code ứng dụng bằng Java.

Đối với mình thì hiện tại chưa phải dùng đến nó nhưng chắc chắc sẽ tìm hiểu kỹ hơn về vấn đề này. Đặc biệt là đối với Liquibase để xem cách sử dụng với các trường hợp sử dụng nó như thế nào.

Hiện tại đối với mình quản lý thủ công bằng SVN hoặc GIT đó là viết ra các script thay đổi về DB để lưu trữ lại thôi. Phức tạp và cả team, nhiều team dùng thì chưa nghĩ đến.