một lần (sửa) báo cáo

💡Bối cảnh tình huống:

Một dự án trong công ty phát hiện ra trên repo dùng cho infrastructure, trong file build có chứa thông tin password không hề được mã hoá (plain password). Mặc dù chỉ có team member được phân quyền mới có thể access repo nói trên nhưng đây vẫn bị xem là một security incident.

Thế là toàn bộ các dự án khác lập tức bị rà soát và dự án của anh A. cũng bị phát hiện có password đang được ghi thẳng (hardcode) vào file config trên repo mà không hề được mã hoá hay masked gì. Với kết quả này, công ty đã ra chỉ thị cho team dự án của A. phải đổi password và xóa credentials khỏi repo a.s.a.p (càng sớm càng tốt).

📍Lần đầu tiên A. gặp phải tình huống lửa cháy (incident) ở chỗ khác rồi liên đới sang chỗ mình như vậy nên A. hơi hoang mang. Nếu là incident thì phải báo cáo với khách hàng ngay, thế nhưng không biết cái này có phải là incident của team mình không? Thấy bên Dev. Manager và team đang trao đổi với nhau, hay là cứ đợi? …

Đang suy nghĩ như vậy thì A. được gọi vào voice chat với cấp trên và được yêu cầu đại loại:

• 💢 “cần xem xét việc nào cần làm ngay và tập trung xử lý luôn.
• 💢 điều gì chưa rõ thì đưa lên hỏi Dev. manager thay vì chờ đợi …”

Vậy là A. phải vào việc.

Từ góc độ BrSE., A. sẽ phải quan tâm đến việc thông báo, giải thích và đề xuất phương án với khách hàng. Lần này yêu cầu xuất phát từ phía công ty, thế nên A. cần nhanh chóng tập hợp thông tin từ team để có nội dung liên lạc với phía khách.

📍 Để có thông tin. A. yêu cầu team cung cấp:

• . Danh sách các tác vụ cụ thể cần đối ứng
• . Kế hoạch thời gian dự kiến thực thi các tác vụ ấy
• . Ảnh hưởng (Vd. downtime ….) đến người dùng hệ thống

Còn lại, phần Lý do tại sao (why) cần làm các tác vụ ấy thì A. sẽ tự tóm tắt dựa trên bối cảnh và các chi tiết kỹ thuật mà team đã báo lại trên slack.

Lát sau A. nhận được thông tin từ team. Trước áp lực hành động và trong tâm trạng lo lắng, , A. bắt tạm các keyword kỹ thuật team đưa và soạn một báo cáo như sau:

a.⚠️【Thông báo việc thay đổi mật khẩu RDS】
Thông qua kiểm tra định kỳ security, chúng tôi đã phát hiện trong dự án này, RDS đang sử dụng một password đang được hardcode từ thời điểm build dự án ban đầu.
Password này được sử dụng bởi infra team để tạo các RDS instance cho môi trường Dev., staging và production trong giai đoạn đầu và hiện tại đã được vô hiệu hoá bằng cách giới hạn IP truy cập.
Tuy nhiên, nhằm nâng cao tính bảo mật, chúng tôi sẽ thay đổi mật khẩu này sang GitLab variable và tiến hành thay thế.
Chúng tôi dự kiến sẽ thực hiện công việc vào khung giờ dưới đây.

• Thời gian dự kiến thực hiện: …

Rất xin lỗi vì thông báo đột ngột và vì sự bất tiện, tuy nhiên do lý do bảo mật, chúng tôi cần xử lý nhanh chóng. Kính mong quý vị thông cảm và hỗ trợ.

Gửi nội dung trên để cấp trên review. Không lâu sau A. nhận được nhận xét:

• ❗.hãy viết ngắn gọn/ cô đọng hơn,
• ❗.btw em đang viết theo hướng giảm nhẹ bản chất,
• ❗ .còn anh nghĩ nên nói thật bản chất, chỉ giảm nhẹ ở từ ngữ thôi
• ❗. tham khảo cách viết của bên Nhật cho vụ việc (incident) gốc nhé …..

Đang vội đối ứng nhiều task khác nữa nên A. chỉ thay đổi tiêu đề cho đúng bản chất và tham khảo AI để thu gọn lại rồi gửi cho cấp trên bản sửa:

b. ⚠️【Phát hiện vi phạm security policy】

Kính gửi Quý công ty,

Qua kiểm tra security định kỳ, chúng tôi đã phát hiện CI/CD repository của dự án có chứa password được hardcode.

• Nguyên nhân: Được sử dụng infra team khi deploy môi trường, hiện tại đã bị vô hiệu hóa nhờ giới hạn IP.
• Đối sách: Password sẽ được thay thế bằng GitLab variable.
• Thời gian thực hiện: …..

Rất xin lỗi nhưng vì lý do an toàn bảo mật, chúng tôi rất mong nhận được sự hiểu biết và hỗ trợ từ Quý công ty để xử lý nhanh chóng.

Tưởng thế là ổn, không ngờ khoảng 1 tiếng sau, cấp trên comment lại A. còn dài hơn lần trước:

• >Nguyên nhân: Được sử dụng infra team khi deploy môi trường, hiện tại đã bị vô hiệu hóa nhờ giới hạn IP.
• ❗.câu này bị mix giữa Nguyên nhân và Đánh giá rủi ro rồi em
• ❗.Nên tách phần giải tình Risk ra riêng, ngoài ra , đánh giá  là “vô hiệu hóa nhờ giới hạn IP” thì anh thấy ko chính xác,
• ❗.bản chất là “access được hạn chế” chứ ko phải bản thân thông tin senstive đó “đã bị vô hiệu hoá”.
• ❗.em nên tham khảo đánh giá này: ………(một nội dung phân tích rủi ro kỹ thuật cho incident gốc)… …….

Đến đây A. đơn thuần tách thêm mục Phạm vi ảnh hưởng mới, chuyển ý bị mix (trộn lẫn) ra khỏi Nguyên nhân và đưa vào mục đó, bỏ “vô hiệu hoá” đi và thêm ý “access được hạn chế” vào. Cuối cùng là copy thêm đoạn phân tích nội dung ở chỗ cấp trên bảo “tham khảo” vào và gửi lại:

c. ⚠️【Phát hiện vi phạm security policy】

…. (lược bớt)

Nguyên nhân : infra team đã tiện tay sử dụng trong quá trình thiết lập môi trường lúc đầu.
Ảnh hưởng :

• Thông tin bị rò rỉ nằm trong phạm vi source code và chỉ giới hạn ở những member có quyền truy cập.
• Chỉ truy cập được khi IP address nằm trong whitelist.
• Thông tin API credentials được mã hóa trong bảng credentials, encryption key không được lưu trữ trong database hay source code của các dự án khác.

…… (lược bớt)

📍5 phút sau A. lại nhận được comment mới!

>. Thông tin API credentials được mã hóa trong bảng credentials, encryption key không được lưu trữ trong database hay source code của các dự án khác.

• .ý trên chỉ phù hợp với dự án nơi đã phát hiện incident thôi, ko relevant (phù hợp) với dự án của em,
• . Dự án của em thì ngoài việc hạn chế IP thì còn hạn chế cả bằng SSH rsa authen nữa. Tức là để access được DB thì:
  . IP phải được whitelist
  . Phải qua được ssh rsa authen (cái này phải config trên bastion thì mới có)
  . Có DB’s user/ password (cái mà đang bị “lộ”)
• vì thế, phần giải thích risk này mình cần customize cho phù hợp với dự án mình nhé
• . sau khi hòm hòm nội dung, em bảo AI format lại sang PREP trước khi gửi lại anh.
• .anh sẽ dùng AI check cả xem Nguyên diễn đạt như vậy đã hợp lý chưa? có cần sửa không?

Không hay rồi, copy text từ chỗ khác mà không xem nó có phù hợp với tình huống hiện tại không? Lại còn phải nghe cấp trên “chỉ dạy” thêm về “làm sao để access được DB” trong dự án của mình nữa! Haizz

📍A. bỏ phần giải thích không phù hợp liên quan đến API đi, thêm các ý IP whitelist và SSH vào, dùng AI để format lại theo PREP rồi gửi lại nội dung báo cáo:

d. ⚠️【Phát hiện vi phạm security policy】

… (lược bớt)

Nguyên nhân : Password này được infra team tiện tay sử dụng trong quá trình thiết lập môi trường lúc đầu.
Ảnh hưởng : Rủi ro rò rỉ thông tin được đánh giá là thấp. Dù có password, việc access vào database vẫn cần các điều kiện sau:

• IP phải được đăng ký trong whitelist.
• Phải vượt qua xác thực SSH RSA.

… (lược bớt)

📍Lần A. gửi đi một lúc rồi mà không thấy comment quay lại nhanh chóng như mấy lần trước. Tận 30 phút sau mới có, nhưng chẳng phải comment mà là nội dung cấp trên tự tay sửa và yêu cầu dùng A. dùng để liên lạc với khách hàng.

e. ⚠️【Vấn đề bảo mật】(Cần bàn phương án xử lý)

Kính gửi Quý công ty,

Xin lỗi vì thông báo đột ngột,
Qua quá trình kiểm tra security, chúng tôi phát hiện trong file config CI/CD thuộc dự án có ghi password của database.
Chúng tôi đánh giá vấn đề này cần được xử lý nhanh chóng.

Nguyên nhân trực tiếp :
Năm 20xx, infra team đã trực tiếp ghi password này vào file config để phục vụ việc thiết lập môi trường ban đầu.

Về rủi ro security :
Rủi ro rò rỉ thông tin được đánh giá là thấp. Lý do là để truy cập vào database, ngoài password, cần thêm các điều kiện sau:

• IP address phải được đăng ký trong whitelist.
• Cần xác thực bằng SSH RSA.

Phương án xử lý :
Thay thế password này bằng GitLab variable.

Thời gian thực hiện : …

Rất xin lỗi vì sự bất tiện, nhưng chúng tôi rất mong nhận được sự hiểu biết và phê duyệt phương án xử lý trên từ Quý công ty.

📍Có thể thấy trong nội dung trên, phần tiêu đề, mô tả hiện tượng đã được sửa lại tương đối. Việc phải “cần có action” được nêu bật ngay từ đầu, ngoài ra một ít ngôn từ chi tiết cũng được sửa theo hướng cụ thể hoá hơn. Phần cuối cũng nêu rõ yêu cầu khách hàng trả lời/ phê duyệt phương án xử lý

Đến đây, A. nhìn lại phiên bản đầu tiên và cuối cùng của nội dung báo cáo lần này:

Giữa những tình huống đột ngột, những chỉ thị nhiều kiểu, những thông tin đa chiều, nhiều cấp độ khác nhau, trộn lẫn cả những thông tin mơ hồ hoặc gây nhiễu, đối phó với áp lực từ bên ngoài và đối phó cả những lo lắng bên trong, giữ được suy nghĩ mạch lạc và truyền đạt đúng bản chất vấn đề một cách logic là một đòi hỏi trong nghề BrSE.

Hãy kiên trì tiến lên và không quên có lúc nhìn lại, rút ra bài học từ quá khứ