Thursday, November 15, 2007

Những điều cần biết về bảo mật nguồn mở

Xem hình

Bạn nên vận hành tường lửa hoặc IDS (Intrusion Detection System – hệ thống phát hiện xâm nhập) của công ty mình bằng một công cụ nguồn mở hay bằng một phần mềm thương mại?

Hãy
cùng lắng nghe những lý lẽ thường được các bên đưa ra nhất trong cuộc
“khẩu chiến” về bảo mật nguồn mở và xem xét liệu chúng có ý nghĩa như
thế nào trong thực tế.









Các phần mềm nguồn mở - nhanh chóng, phổ biến, thực tiễn và hơn cả là chúng được dùng miễn phí. Ảnh: Karmaweb.


Nghiên cứu nhiều hơn đồng nghĩa với an toàn hơn?


Một
trong số những lý lẽ được viện dẫn nhiều nhất khi đánh giá tính bảo mật
tương đối của các phần mềm nguồn mở là “để mắt nhiều hơn tới mã nguồn
đồng nghĩa với việc giảm thiểu các vấn đề về bảo mật.”


Nói
cách khác, việc nghiên cứu mã nguồn cơ sở kỹ lưỡng hơn ở các khâu thử
nghiệm, đánh giá, kiểm định và sửa lỗi sẽ trực tiếp tạo ra những phần
mềm ngày càng mạnh. Điều này đương nhiên đúng. Tuy nhiên, ý kiến cho
rằng các dự án nguồn mở thường an toàn hơn vì mã nguồn sẵn có (và vì
thế sẽ được nghiên cứu nhiều hơn) vẫn còn rất mập mờ.


Hãy
đối diện với thực tế rằng không phải các phần mềm đều được tạo ra như
nhau. Một số nhà phát triển phần mềm rất chuyên tâm đến quá trình thử
nghiệm và kiểm định trong khi số khác thì không.


Trong
khi các ứng dụng nguồn mở được sử dụng nhiều và thường xuyên được “bảo
trì” như Apache và OpenSHH có thể được nghiên cứu rất nhiều (cả từ phía
cộng đồng và các cá nhân), thì các ứng dụng ít tiếng tăm hơn hoặc các
ứng dụng không được bảo trì thường xuyên lại không có được “đặc ân” đó.


Hãy
nhớ rằng, mã nguồn của một phần mềm nhất định được công bố rộng rãi
không nhất thiết có nghĩa là tất cả mọi người sẽ đều để mắt đến nó. Vì
lẽ đó, các đại lý phần mềm thương mại cũng rất khác nhau – một số rất
quan tâm đến việc mã nguồn của họ phải được thử nghiệm và kiểm định kỹ
lưỡng trong khi số khác lại ít quan tâm hơn.


Một
số đại lý sẵn sàng cung cấp mã nguồn cho những người sử dụng nhất định
(ví dụ như những khách hàng mua với số lượng lớn) hoặc cho cộng đồng
nói chung, miễn là việc bảo hộ sở hữu trí tuệ của họ phải được đảm bảo.


Hỗ trợ và trách nhiệm đồng nghĩa với an toàn?


Những
người ủng hộ bảo mật phần mềm thương mại thường cho rằng mối quan hệ
hợp đồng giữa đại lý và người mua trong các thỏa thuận cấp phép sử dụng
phần mềm thương mại sẽ quy định một mức độ trách nhiệm mà trong nguồn
mở không có.


Theo
đó, nếu một lỗi bảo mật được phát hiện hoặc nếu sản phẩm không hoạt
động như đã quảng cáo thì một bên (đại lý) có thể sẽ phải chịu trách
nhiệm sửa chữa, cập nhật sản phẩm hoặc cung cấp những hỗ trợ đầy đủ để
sản phẩm (hoặc tính năng của sản phẩm) hoạt động tốt.



lẽ được đưa ra ở đây là các phần mềm nguồn mở không có những mối quan
hệ như vậy và vì thế sẽ kém an toàn hơn các phẩn mềm thương mại ở một
mức độ nào đó.



lẽ này có ý nghĩa thế nào trong thực tế còn tùy thuộc. Vì không phải
tất cả phần mềm và các hỗ trợ đều được tạo ra giống nhau. Trong một số
trường hợp, chính các nhà phát triển nguồn mở cung cấp hỗ trợ đối với
các dự án mà người sử dụng cần, nhưng cũng có trường hợp mà một bên thứ
ba độc lập cung cấp hỗ trợ dành cho công cụ nguồn mở.


Ngoài
ra, nhiều sản phẩm nguồn mở rất nhiệt tình đưa ra giải đáp đối với
những vấn đề được hỏi thông qua các lưu trữ danh sách thư tín và các
website cơ sở kiến thức.


Việc
có được giải đáp đối với những vấn đề được hỏi hay không còn tùy thuộc
vào dự án nguồn mở cụ thể được cân nhắc – các dự án lớn thường dễ dàng
đưa ra được giải đáp đối với những câu hỏi có liên quan.


Tương
tự, các đại lý cung cấp các mức độ hỗ trợ khác nhau. Yêu cầu cụ thể của
bạn có nhận được sự chú ý hay không sẽ phụ thuộc vào loại quan hệ hỗ
trợ có trong hợp đồng và các chính sách hỗ trợ cụ thể của đại lý đó.
Đừng quên rằng: bạn trả tiển để có được hỗ trợ không có nghĩa là bạn sẽ
có được hỗ trợ tốt và các hỗ trợ miễn phí cũng không có nghĩa là chúng
không tốt.


Nhiều cập nhật hơn đồng nghĩa với an toàn hơn?


“Phát
hành sớm và thường xuyên” là phương thức được nhiều dự án nguồn mở áp
dụng. Đối với nhiều dự án nguồn mở, việc các bản sửa lỗi bảo mật cần
được cung cấp cho người sử dụng phần mềm ngay tức thì để các nhà quản
lý có thể nhanh chóng xử lý các vấn đề tiềm ẩn từ lâu đã được coi như
một triết lý nằm lòng.


Theo
quan điểm này, các nhà quản lý sẽ được thông báo càng sớm càng tốt về
các vấn đề bảo mật và được cung cấp một giải pháp hoặc một bản vá lỗi
mà họ có thể ngay lập tức ứng dụng để đảm bảo rằng hệ thống của họ vẫn
được an toàn – hoặc ít nhất họ có thể biết rõ về vấn đề để có thể kiểm
soát, đề phòng tin tặc lợi dụng.


Ngược
lại, nhiều đại lý phần mềm thương mại đưa ra các bản vá lỗi theo một kế
hoạch được định trước, ví dụ theo từng tháng hoặc từng quý.


Triết
lý của họ là giữ các vấn đề về bảo mật càng bí mật càng tốt, cho tới
khi bản sửa lỗi đã sẵn sàng, khi đó, bằng cách phát hành bản khắc phục
theo một thời gian biều định trước, các nhà quản lý có thể lập kế
hoạch, thử nghiệm, và bố trí các bản khắc phục đó một cách có kiểm soát
để có thể giảm thiểu tối đa ảnh hưởng đối với quá trình hoạt động của
sản phẩm.


Cả
hai triết lý này đều có chung một mục đích. Cả “phát hành sớm và thường
xuyên” và phát hành theo thời gian biều đều nhằm mục đích giúp cho nhà
quản lý bố trí các bản vá lỗi, các bản khắc phục một cách dễ dàng.


Vậy
thì phương pháp nào tốt hơn hoặc an toàn hơn? Điều này phụ thuộc vào
các đặc thù của môi trường. Cơ quan của bạn có phải là môi trường làm
việc với các quản lý có khả năng phản ứng nhanh đối với các thay đổi
liên quan đến bảo mật, hay là nơi không yêu cầu nhiều quá trình lập kế
hoạch và phân bổ nguồn lực đối với các thay đổi liên quan đến sản
phẩm…?


Vậy phần mềm nguồn mở hay phần mềm thương mại an toàn hơn?


Câu trả lời phụ thuộc vào công việc kinh doanh của bạn cũng như các sản phẩm cụ thể. Cũng
giống như khi hỏi “liệu ô tô của Ford có nhanh hơn ô tô của GM?”, câu
trả lời sẽ phụ thuộc vào Ford và GM. Không một loại sản phẩm phần mềm
nào có thể đáp ứng được nhu cầu của tất cả mọi nguời, một sản phẩm tốt
hơn dành cho người khác chưa chắc đã tốt hơn đối với bạn.



(Theo VTC)

No comments: