Khoảng một năm rưỡi trước, tôi chuyển đến một công ty mới và bắt đầu làm việc với tư cách là DBA của họ. Công ty trước đây không áp dụng bất kỳ bản vá lỗi nào cho bất kỳ cơ sở dữ liệu Oracle nào. Kể từ khi tôi ở đây, tôi đã thấy bảo mật hệ thống CNTT trở thành trọng tâm hơn và trải qua mức độ giám sát cao hơn mà trước đây đã thấy. Thay vì đợi lệnh bắt đầu triển khai các bản vá bảo mật thường xuyên cho cơ sở dữ liệu Oracle của chúng tôi, tôi quyết định chủ động. Sẽ đến ngày chúng tôi được yêu cầu bắt đầu vá cơ sở dữ liệu Oracle của mình một cách thường xuyên và tôi muốn nói rằng chúng tôi đã triển khai nó.
CPU tháng 4 năm 2012 vừa được phát hành vào tuần trước và đây là CPU đầu tiên mà chúng tôi sẽ áp dụng cho cơ sở dữ liệu Oracle của mình. Trước khi tôi áp dụng CPU đầu tiên, tôi đã suy nghĩ một chút về cách thực hiện sự thay đổi này trong môi trường doanh nghiệp của chúng tôi. Tôi quyết định chia sẻ một vài trong số những thay đổi đó trong trường hợp bất kỳ ai khác gặp phải tình huống tương tự trong tương lai.
1. 3 D’s:Trước khi bất kỳ bản vá nào bắt đầu, chính sách vá lỗi đã được Tài liệu hóa, Phổ biến cho nhân viên CNTT và ban quản lý, và Thảo luận. Tài liệu này đã thảo luận ở cấp độ cao, sự cần thiết của các bản vá bảo mật thường xuyên, khi nào các bản vá bảo mật sẽ ra mắt và cách chúng sẽ được áp dụng cho hệ thống của chúng tôi để giảm rủi ro cho cơ sở dữ liệu, ứng dụng và người dùng cuối.
2. Patch Timeline - Tôi rất có thể sở hữu một bản sao cơ sở dữ liệu sản xuất của chúng tôi chỉ để sử dụng cho DBA chứ không phải ai khác. Dòng thời gian của tôi bắt đầu từ đó. Trong vòng một tuần kể từ khi CPU phát hành, tôi sẽ áp dụng CPU vào cơ sở dữ liệu DBA của mình và giải quyết mọi sự cố. Với hai tuần kể từ khi phát hành CPU, tôi sẽ áp dụng bản vá cho cơ sở dữ liệu phát triển của chúng tôi. Trong vòng một tháng kể từ khi phát hành CPU, tôi sẽ áp dụng bản vá cho cơ sở dữ liệu Thử nghiệm và Giai đoạn. Và cuối cùng, trong vòng 6 tuần kể từ khi phát hành CPU, tôi sẽ áp dụng bản vá cho quá trình sản xuất. Đây chỉ là dòng thời gian của tôi và những gì hoạt động trong môi trường của chúng tôi. Dòng thời gian của bạn có thể khác. Nhưng điều quan trọng là mọi người phải hiểu dòng thời gian và dòng thời gian thực hiện hai điều dường như trái ngược nhau - 1) áp dụng bản vá từ từ để mọi vấn đề về cơ sở dữ liệu hoặc ứng dụng được sắp xếp trước khi tiến hành bước tiếp theo trong dòng thời gian. Một khi bản vá được đưa vào sản xuất, không có gì ngạc nhiên và tin tưởng rằng bản vá sẽ không phá vỡ bất cứ điều gì. 2) Áp dụng bản vá đủ nhanh để các lỗ hổng bảo mật được cắm vào thời gian hợp lý. Trong môi trường của tôi, sáu tuần để sản xuất là đủ chậm để giải quyết các vấn đề nhưng nhanh nhất là chúng tôi cảm thấy thoải mái khi tiếp tục. Môi trường của bạn có thể có các mốc thời gian khác.
3. Ghi nhật ký - Tôi thực sự cảm thấy rằng các bản vá lỗi nên được ghi lại trong một số loại nhật ký thay đổi. Với nhật ký, bạn sẽ có thể quay lại và xem chính xác thời điểm từng bản vá được áp dụng cho mỗi cơ sở dữ liệu. Điều này có thể đi một chặng đường dài trong việc chẩn đoán liệu bản vá có phải là nguyên nhân gây ra sự cố hay không. Nếu tôi nhận được một phiếu phạt mà quy trình có lỗi và vấn đề được ghi nhận lần đầu tiên vào ngày 1 tháng 5, thì tôi có thể xem nhật ký thay đổi. Nếu tôi áp dụng bản vá vào ngày 30 tháng 4, thì bản vá có thể đã gây ra sự cố. Nhưng nếu tôi áp dụng bản vá vào ngày 2 tháng 5 và sự cố đã tồn tại trước đó một ngày, thì bản vá không phải là nguyên nhân của sự cố. Một số tổ chức đã có sẵn cơ chế Kiểm soát Thay đổi và nhật ký vá lỗi Oracle phải phù hợp với cấu trúc đó.
4. Kiểm tra / Kiểm tra / Kiểm tra - Là một DBA, chúng tôi có nhiệm vụ đảm bảo rằng các thay đổi được đưa vào sản xuất có mức độ tin cậy cao rằng ứng dụng sẽ không bị phá vỡ. Điều tối quan trọng là phải kiểm tra các thay đổi của bạn và các bản vá không có gì khác biệt. Nếu bạn không xem qua dòng thời gian vá lỗi của mình, bạn sẽ không có đủ thời gian để kiểm tra và nếu có vấn đề mà bản vá đã đưa vào môi trường của bạn, đó sẽ là sự tự sát nếu bạn không kiểm tra đầy đủ trước khi bắt đầu sản xuất.
5. Sao lưu - Người ta phải sao lưu cơ sở dữ liệu và thư mục chính Oracle đang được vá trước khi áp dụng bản vá. Bạn không bao giờ biết liệu mình có phải quay lại điểm trước đó trước khi vá lỗi ở một hoặc cả hai khu vực đó hay không. Thỉnh thoảng người ta nên kiểm tra phương pháp khôi phục hoặc sao lưu các bản vá trước khi sản xuất. Việc kiểm tra này có thể không nhất thiết phải thực hiện mỗi quý một lần, nhưng nên thực hiện ít nhất mỗi năm một lần.
Tôi nghĩ những điều đó bao hàm những suy nghĩ chính mà tôi có về chủ đề này. Nếu bạn có câu hỏi / nhận xét, hãy cho tôi biết.
