DevSecOps là gì?

DevSecOps nghe qua như là một role bị nhồi nhét quá nhiều yêu cầu khi đòi hỏi đủ kỹ năng từ Development, Security và cả Operations. Tuy nhiên theo cá nhân mình thấy đây là một xu thế tất yếu khi việc thúc đẩy nâng cao security sau khi ứng dụng đã hoàn thiện có thể gây ra chi phí lớn hơn nhiều khi so sánh với việc tích hợp những cơ chế bảo mật ngay từ đầu.

DevSecOps không bao gồm hết tất cả công việc của team Security, DevSecOps tập trung vào việc áp dụng các cơ chế bảo mật cho những phần việc hiện hữu của một DevOps Engineer như: CI/CD, Observability, IaC, Access Management, Policies, Governance,....

Với sự đe dọa ngày càng hiện hữu từ các mô hình AI có thể tự phát hiện lỗ hổng 0 day như hiện nay, việc quan tâm hơn về bảo mật nói chung hay bảo mật trong quá trình phát triển phần mềm sẽ càng ngày càng được quan tâm.

Làm sao để đánh giá hiệu suất team DevSecOps?

Thường khi đi làm chúng ta sẽ có mục tiêu công ty trong năm, rồi sẽ chia ra mục tiêu phòng ban, từ mục tiêu phòng ban sẽ làm rõ ra mục tiêu đội nhóm. Nếu đạt mục tiêu này thì nhiều thưởng, nhiều tiền, ngược lại thì đói nên hãy bắt đầu với mục tiêu của một đội nhóm DevSecOps.

DORA metrics bao gồm: Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service là một bộ metrics khá phổ biến để đo lường hiệu suất một team DevOps, bộ metrics này xoay quanh mục tiêu của DevOps Engineer là đẩy nhanh quá trình phát triển sản phẩm. Tuy nhiên đối với một DevSecOps Engineer, DORA metrics sẽ chỉ còn có thể đánh giá một phần mà thêm vào đó ta sẽ có thêm 1 số metrics liên quan đến security, ví dụ như:

Tùy vào từng đội nhóm, ta có thể chọn ra một số những metrics mà ta thấy phù hợp để đo lường cho team.

DevSecOps làm gì khác so với DevOps Engineer?

Từ việc xây dựng mục tiêu khác sẽ yêu cầu đội nhóm cần làm khác đi, tích hợp các công cụ và phương pháp để đạt được mục tiêu bên trên.

CI/CD Pipeline

Đây là một phần được xây dựng nhiều nhất. Thay vì chỉ chạy Build => Test => Deploy, một DevSecOps Engineer sẽ tích hợp thêm các đầu công việc:

Trước khi deploy:

• Secrets scanning: Gitleaks
• Static Application Security Testing (SAST): Sonarqube, Semgrep,...
• Dependency scan: Trivy, Grype, Synk,...
• Image Signing: Cosign
• Container image scanning: Trivy,...

Sau khi deploy:

• Dynamic Application Security Testing: ZAProxy, Burp Suite,...
• Runtime threat detection: Falcon, Defender for containers,...

Infrastructure as code

IaC hiện đang là một quy chuẩn được theo đuổi bởi rất nhiều đội nhóm hiện tại. Đây là nơi đầu tiên hạ tầng được xây dựng vì vậy việc đảm bảo bảo mật từ gốc là rất quan trọng. DevSecOps Engineer sẽ đảm bảo:

• Tích hợp static code analysis for Helm, TF code: Checkov, tfsec
• Review sự thay đổi để xem: có mở các port không cần thiết?, quyền được cấp sai hoặc vượt quá nhu cầu?,...

Access and Identity

Thay vì cấp quyền thủ công hoặc bừa bãi cho stakeholders, DevSecOps sẽ tập trung vào nguyên tắc Zero Trust sử dụng các công cụ để cung cấp quyền cho developers hay các team khác:

• Không có credential nào sống quá lâu, credential sẽ luôn hết hạn sau một khoảng thời gian và cần được yêu cầu để lấy credential mới (Managed Identity - Azure, Workload Identity - GCP,..)
• Mặc định chỉ cung cấp quyền tối thiểu Least-priviledge, user cần quyền gì thêm sẽ cần yêu cầu và được phê duyệt (PIM - Azure).
• Cung cấp quyền truy cập đặc quyền trong thời gian ngắn (PAM)
• Username - password của các dịch vụ sẽ cần được thu hồi và cấp phát lại định kỳ (3 - 6 - 12 tháng)

Policies and governance

Việc dễ nhất để đảm bảo tất cả tài nguyên đều tuân theo một quy chuẩn là xây dụng các bộ chính sách được áp dụng cho tài nguyên trên diện rộng. Từ chối khởi tạo các tài nguyên không tuân thủ nguyên tắc.

Container workload (Kyverno, OPA/Gatekeeper,...)

• Chỉ sử dụng signed image, trusted image
• Bắt buộc sử dụng non-root user trong container thông qua securityContext đối với K8s
• Áp dụng network policies để kiểm soát lưu lượng mạng trong K8s Cluster
• ....

Observability

Đôi khi chúng ta đã áp dụng đủ cách để kiểm soát từ đầu vào nhưng lỗ hổng bảo mật vẫn có thể tồn tại và được đẩy lên môi trường thực tế. Chính vì vậy chúng ta cần giám sát liên tục để phát hiện ra những hành vi lạ, bất thường trong môi trường ứng dụng hoạt động. Sau đây là một vài yếu tố có thể cân nhắc giám sát:

• Phát hiện leo thang đặc quyền trong container (Falcon, Defender for containers,...)
• Phát hiện số lượng yêu cầu xác thực bất thường (Prometheus exporter & grafana,....)
• Theo dõi dữ liệu đầu vào bất thường (Tracing tools)
• ....

Incident response

Là một DevSecOps Engineer, mình tin rằng việc xây dựng các kịch bản để ứng phó với các sự cố bị tấn công cũng rất quan trọng. Không chỉ là kich bản chung chung cho khắc phục rồi khôi phục hệ thống. Kịch bản cần có:

• Lưu trữ lại bằng chứng như logs, metrics , traces,... trong quá trình xảy ra sự cố
• Cách thức khoanh vùng hệ thống bị ảnh hưởng.
• Cách hành động cho từng loại đe dọa cụ thể như: bị mã hóa dữ liệu, bị tấn công ddos,...

Kết

Cám ơn bạn đã đọc đến hết bài. Bài viết dựa trên những hiểu biết của mình tìm hiểu được về DevSecOps. Security là một chủ đề rất rộng và chắc chắn bài viết vẫn còn nhiều thiếu sót. Bạn có ý kiến gì khác hãy để lại ở phần bình luận nhé.

Hy vọng bài viết giúp bạn có thêm 1 vài ý tưởng trong công việc. Have a good day!