An ninh thông tin và máy tính bao trùm bên trong rất nhiều lĩnh vực. Mỗi lĩnh vực có những lỗ hổng an ninh và một số biện pháp đối phó tương ứng, chúng cung cấp mức độ bảo mật và bảo vệ tốt hơn. Việc không hiểu rõ về các lĩnh vực, các mức độ an ninh của Network Devices, OS, Hardware, Protocols và Applications, có thể gây ra những lỗ hổng bảo mật nghiêm trọng ảnh hưởng đến tổng thể toàn bộ môi trường.

Hai khái niệm cơ bản trong ATTT chính là Security Policy - Chính Sách Bảo Mật và Security Model - Mô Hình Bảo Mật.

Security Policy - Chính sách bảo mật vạch ra cách truy cập của các thực thể [entities] khác nhau, những hoạt động mà các thực thể này có thể thực hiện, mức độ bảo vệ cần thiết cho một hệ thống hoặc một sản phẩm phần mềm, những hành động cần phải diễn ra khi những sự cần thiết này không được đáp ứng, Chính sách vạch ra những kỳ vọng mà các Hardware và Software bắt buộc phải đáp ứng để được xem là có tính tuân thủ.

Security Model - Mô hình bảo mật vạch ra những yêu cầu cần thiết để hỗ trợ và thực hiện một chính sách bảo mật nào đó. Nếu Chính Sách Bảo Mật chỉ ra rằng, tất cả mọi người dùng đều bắt buộc phải identified, authenticated và authorized trước khi truy cập vào tài nguyên mạng, thì Mô Hình Bảo Mật có thể đặt ra một Access Control Matrix để đáp ứng các yêu cầu của chính sách bảo mật.

Nếu Chính Sách Bảo Mật tuyên bố rằng, không một ai ở Lower Security Level có thể xem hoặc chính sửa thông tin ở Higher Security Level, thì Mô Hình Bảo Mật sẽ vạch ra những quy tắc và logic cần phải được thực hiện để đảm bảo một đối tượng ở mức độ an ninh thấp không thể nào truy cập trái phép vào các đối tượng ở mức độ an ninh cao hơn. Security Model mang đến một lời giải thích sâu sắc về cách Hệ Điều Hành cần được phát triển để support cho một chính sách bảo mật nào đó.Chú ý : Các hệ thống và các thiết bị có thể có chính sách bảo mật của riêng chúng. Đây không phải là các chính sách an ninh của tổ chức mà có chứa chỉ thị của Management. Security Policies của các hệ thống và Models mà chúng sử dụng, cần được thực thi ở một mức độ cao hơn so với chính sách bảo mật của tổ chức [organization security policy]. System Policy - Chính sách hệ thống chỉ ra mức độ an ninh cần được cung cấp bởi các thiết bị hoặc các hệ điều hành.

Computer Security - Bảo Mật Máy Tính có thể là một thuật ngữ khó hiểu, bởi vì nó mang nhiều ý nghĩa khác nhau đối với những người khác nhau. Nhiều khía cạnh của một hệ thống có thể được đảm bảo an toàn, Security có thể xảy ra ở các cấp độ và các mức độ khác nhau. Như đã nêu trong những chương trước, An Toàn Thông Tin bao gồm những thuộc tính chính sau đây :

• Availability : Phòng chống việc tổn thất hoặc thiệt hại đến khả năng truy cập vào dữ liệu và tài nguyên • Integrity : Phòng chống việc thay đổi, chỉnh sửa trái phép dữ liệu và tài nguyên • Confidentiality : Phòng chống việc tiết lộ trái phép dữ liệu và tài nguyên

Những thuộc tính này thường sẽ chia thành nhiều thuộc tính bảo mật chi tiết hơn, chẳng hạn như : authenticity - tính xác thực, accountability - tính trách nhiệm [logging, audit], nonrepudiation - chống chối bỏ và dependability - tính tin cậy. Làm thế nào để tổ chức biết được họ cần thuộc tính nào, mức độ mà họ cần, liệu các HĐH và các ứng dụng mà họ sử dụng có thực sự cung cấp được những thuộc tính này hay không ?

Những câu hỏi này sẽ phức tạp hơn nhiều so với các câu hỏi trả lời thuần túy về sản phẩm. Nhiều tổ chức họ không chỉ quan tâm về việc mã hóa Email khi gửi chúng đi xuyên qua mạng lưới Internet, mà họ còn quan tâm về tính bảo mật của dữ liệu được lưu trữ trong Databases, quan tâm về vấn đề bảo mật của Web Farms được kết nối trực tiếp ra Internet, tính toàn vẹn của giá trị dữ liệu nhập vào Applications, người dùng nội bộ có chia sẻ trade secrets hay không, quan tâm về những kẻ tấn công ở bên ngoài, vấn đề về Viruses, tính nhất quán của Data Warehouses, và còn nhiều nhiều thứ nữa [thật dọa người].

Những vấn đề này không chỉ ảnh hưởng đến năng suất và lợi nhuận, mà còn liên đới đến vấn đề pháp luật và trách nhiệm pháp lý trong việc bảo vệ dữ liệu.

Các công ty và Management vận hành chúng, có thể phải chịu trách nhiệm trực tiếp nếu có bất kỳ vấn đề nào trong các vấn đề đã đề cập ở trên gặp sự cố. Những vấn đề này rất quan trọng đối với các công ty, để họ biết những gì họ cần phải bảo mật, làm thế nào để đảm bảo họ thực sự được bảo vệ bởi các sản phẩm Security mà họ đã mua.

Rất nhiều vấn đề Security bắt buộc phải được xem qua trước và trong giai đoạn Design & giai đoạn Architectural cho một sản phẩm. Security sẽ tốt nhất, nếu nó được thiết kế và tích hợp vào bên trong nền tảng của ứng dụng, hệ điều hành ; chứ không phải là một phần thêm vào lúc "vô tình nhớ lại".

Khi Security được tích hợp như một phần quan trọng trong giai đoạn Design; có nghĩa nó sẽ được thiết kế [engineered], được triển khai [implemented], được kiểm tra [tested], được kiểm toán [audited], được thẩm định [evaluated], được chứng nhận [certified] và được công nhận [accredited].

Security mà một sản phẩm cung cấp cần phải được xếp hạng [rating] dựa trên 3 thuộc tính : Availability, Integrity và Confidentiality mà sản phẩm đó cung cấp. Khách hàng khi đó sẽ sử dụng những Ratings này để xác định xem, liệu một sản phẩm cụ thể nào đó có cung cấp mức độ bảo mật như họ yêu cầu hay không.

Domain : Security Architecture and Design sẽ đưa chúng ta đi qua những Steps cần thiết, trước khi thực sự bắt tay phát triển một hệ điều hành, cũng như cách thẩm định và xếp hạng những OS, những Applications này bởi tổ chức chính phủ và các cơ quan khác, những Ratings này thực sự có ý nghĩa gì ?

Tuy nhiên, trước khi chúng ta đi sâu vào những khái niệm này, điều quan trọng trước tiên là phải hiểu cơ bản về cách làm việc của một hệ thống máy tính. Các yếu tố này là những mảnh nhỏ tạo nên mọi Computer Architecture - Kiến trúc máy tính.

Computer Architecture - Kiến trúc máy tính

Kiến trúc máy tính bao gồm tất cả các bộ phận của một hệ thống máy tính : OS [hệ điều hành], Memory Chips, Logic Circuits, Storage devices, Input & Output devices, các thành phần Security, Buses, và các thành phần Networking.

Mối quan hệ của tất cả các bộ phận này có thể khá phức tạp, chúng làm việc cùng nhau theo một cách an toàn bao gồm các phương pháp và các cơ chế cực kỳ phức tạp. Cảm ơn thượng đế đã mang lại những con người thông minh cho thế giới , những người đã tìm ra được những thứ này.

Bây giờ chúng ta sẽ được truyền thụ bí kíp cách chúng hoạt động và tại sao chúng lại hoạt động như vậy. Chúng ta sẽ hiểu cách những thành phần này "bắt tay hợp tác" với nhau như thế nào, cũng như chúng ta sẽ càng hiểu hơn về những Vulnerabilities thực sự sẽ diễn ra làm sao, các biện pháp countermeasures để ngăn cản những Vulnerabilities này xảy ra ...

Chú ý : Chương này sẽ xen lẫn kiến trúc Hardware với kiến trúc OS, cũng như các thành phần của chúng; để cho chúng ta hiểu được cách chúng bắt tay làm việc cùng nhau.

The Central Processing Unit - Đơn vị xử lý trung tâm

Central Processing Unit [CPU] là bộ não của máy tính. Tổng quát nói chung, CPU sẽ nhận chỉ thị từ Memory và thực hiện [executes] chúng. Mặc dù CPU là một phần của Hardware, nhưng nó có Instruction Sets của riêng mình [được cung cấp bởi OS] cần thiết để thực hiện các nhiệm vụ của nó. Mỗi loại CPU có một kiến trúc đặc thù và các bộ Instructions của riêng nó. Hệ Điều Hành cần phải được thiết kế để có thể làm việc bên trong CPU Architecture này.

Đây là lý do tại sao một HĐH có thể làm việc trên bộ xử lý Pentium nhưng lại không thể làm việc trên bộ xử lý SPARC.

Chú ý : Scalable Processor Architecture [SPARC] là loại chip Reduced Instruction Set Computing [RISC] được phát triển bởi Sun Microsystems.

Các con Chips bên trong CPU chỉ bao gồm khoảng một vài inches vuông, nhưng chứa hơn 40 triệu transistors. Tất cả hoạt động [operations] bên trong CPU đều được thực hiện bởi các tín hiệu điện ở những Voltages khác nhau, mỗi Transistor sẽ nắm giữ các Voltages này, được đại diện bởi 0's và 1's đến máy tính.

CPU chứa các Registers - Thanh Ghi trỏ đến Memory Locations, Memory chứa Next Instruction để thực thi [executed] và cho phép CPU lưu trữ thông tin trạng thái của dữ liệu cần phải được xử lý.

Register - Thanh Ghi là một vị trí lưu trữ tạm thời. Việc truy cập vào Memory để lấy thông tin Instructions và Data sẽ chậm hơn nhiều so với việc truy cập vào Register, vì nó là một thành phần của chính bản thân CPU. Vì vậy, khi CPU thực hiện xong một công việc [task], nó sẽ hỏi Registers : "Okay, tiếp theo tao phải làm gì nữa đây ?" và Registers nắm giữ thông tin sẽ báo cho CPU biết công việc kế tiếp của nó là gì.

Việc thực thi Instructions sẽ được thực hiện bởi Arithmetic Logic Unit - ALU. ALU thực hiện các chức năng Mathematical - Toán Học và các hoạt động Logical trên Data. ALU có thể được coi là bộ não của CPU, còn CPU là bộ não của máy tính.

Software lưu giữ các Instructions và Data của nó trong Memory. Khi có một hành động nào đó cần phải diễn ra trên Data, Instructions và Data Memory Addresses sẽ được truyền đến CPU Registers, như minh họa trong Figure 5-1.

Hệ Điều Hành và Applications thực sự chỉ tạo ra Lines & Lines of Instructions - Những dòng chỉ thị. Những Instructions này chứa Empty Variables - Các Biến Rỗng, được gắn vào trong thời gian chạy - Run Time. Empty Variables nắm giữ các dữ liệu thực tế [actual data]. Có một sự khác biệt giữa Instructions và Data. Instructions được viết ra để thực hiện một số tính năng lên Data.

Để có ví dụ thực tế rõ ràng dễ hiểu, chúng ta sẽ mở chương trình Calculator lên nhé các bạn đồng liêu !

Trong thực tế, chương trình Calculator chỉ là các Lines of Instructions cho phép chúng ta thực hiện tính toán cộng, trừ, nhân, chia và một số tính năng toán học khác sẽ được thực thi dựa trên Data mà chúng ta cung cấp. Ví dụ, chúng ta gõ vào chương trình tính toán 3 + 5. Khi đó 3 và 5 chính là Data.

Sau khi chúng ta nhấn vào nút = , chương trình Calculator sẽ "nói" cho CPU biết rằng, nó cần thi hành Instruction này lên hai giá trị Data 3 và 5. "Anh Hùng ALU trong CPU" sẽ thực hiện Instruction và trả về kết quả 8 cho chương trình Calculator, hay còn gọi là Requesting Program. Đây chính là giá trị 8 bạn sẽ thấy trong chương trình Calculator khi bấm nút = .

Đối với người dùng bình thường, họ nghĩ rằng có vẻ như chương trình Calculator tự bản nó thực hiện tất cả những việc này, không nhờ "đứa" nào khác cả. Nhưng thực tế không phải vậy, chương trình Calculator không có khả năng này. Nó phụ thuộc vào CPU và các thành phần khác của hệ thống để thực hiện loại hình hoạt động này.

Control Unit - Bộ Kiểm Soát chịu trách nhiệm quản lý và đồng bộ hóa hệ thống, trong khi các Application's Code và Operating System Instructions đang được thực hiện. Control Unit là thành phần Fetches - Nạp Code, Interprets - Diễn dịch Code và giám sát việc thực hiện các Instruction Sets khác nhau. Control Unit sẽ xác định xem Application Instructions nào được xử lý, sắp xếp Priority và Time Slice.

Nó sẽ kiểm soát khi các Instructions được thực thi, việc thực thi này cho phép Applications xử lý dữ liệu. Control Unit không thực sự xử lý dữ liệu. Nó giống như một anh cảnh sát giao thông chịu trách nhiệm báo hiệu khi nào xe dừng và khi nào xe được phép đi, điều này được minh họa rất dễ hiểu trong Figure 5-2.

CPU's Time - Thời gian của CPU được phân ra [sliced] thành những phần riêng lẻ và gán cho các Processes. Đây chính là Time Slicing mà một số ứng dụng và người dùng khờ khạo thường nghĩ rằng hệ thống thực sự thực hiện nhiều chức năng cùng một lúc.

Trong khi hệ điều hành có thể thực hiện nhiều chức năng khác nhau cùng một lúc [Multitasking] thì trong thực tế CPU sẽ thực hiện các Instructions theo một cách tuần tự [chỉ một Instruction tại một thời điểm].

CPU có một số loại Registers khác nhau, chứa thông tin về Instruction Set và Data phải được thực thi.

General Registers - Thanh Ghi Chung được dùng để lưu giữ Variables và các kết quả Temporary - Tạm thời khi ALU hoạt động thông qua các bước thực thi của nó.

Special Register còn được gọi là Dedicated Registers nắm giữ các thông tin như : Program Counter, Stack Pointer và Program Status Word [PSW].

Program Counter Registers chứa Memory Address của Next Instruction sẽ được nạp vào. Sau khi Instruction được thực thi, Program Counter sẽ được cập nhật Memory Address của Next Instruction Set. Nó tương tự như mối quan hệ giữa sếp và cô thư ký xinh đẹp.

Cô thư ký giữ cho sếp của mình luôn làm việc đúng tiến độ, points [trỏ] ông ta đến các công việc cần phải thực hiện. Điều này giúp cho ông sếp chỉ cần tập trung vào việc thực hiện công việc, thay vì phải lo lắng trong đầu không biết phải sắp xếp công việc như thế nào, công việc nào đã làm xong rồi, vân vân.

Trước khi chúng ta tìm hiểu về Stack Pointer, chúng ta cần phải hiểu về Stack trước cái đã. Theo ngữ nghĩa Việt Nam, Stack là Ngăn xếp hay còn gọi là Bộ Xếp Chồng.

Mỗi Process có một Stack của riêng mình, nó là một cấu trúc dữ liệu trong Memory, mà Process có thể Read và Write theo kiểu LIFO. LIFO là "last in first out" tức là dữ liệu nào vào sau cùng, sẽ ra trước tiên. [Vào Sau - Ra Trước]

Để dễ hình dung, bạn có thể liên tưởng đến việc như thế này: Chúng ta có 10 cuốn sách, bạn xếp chúng lên nhau thành 1 chồng, bạn bỏ cuốn đầu tiên vào, sau đó đến cuốn thứ 2, thứ 3, ...cuốn thứ 10 là cuốn được bỏ vào sau cùng. Như vậy, cuốn thứ 10 là cuốn vào sau cùng nhưng sẽ được lấy ra đầu tiên, cũng như cuốn thứ 1 được vào đầu tiên nhưng lại ra sau cùng, do ta phải rút từng cuốn một ra thì mới đến lượt nó [trừ ông nào bá đạo bảo rút ngay đít chồng sách].

Cho một ví dụ khác, hai chúng ta cần giao tiếp với nhau thông qua một Stack. Những gì anh sẽ làm chính là đặt tất cả những điều anh muốn nói với em vào một chồng giấy -Stack of Papers.

First Paper - Tờ đầu tiên, anh sẽ cho em biết cách phản hồi đến anh khi cần thiết, đây gọi là Return Pointer. Next Paper - Tờ tiếp theo chứa một số Instructions mà anh cần em thực hiện. Tờ tiếp theo nữa chứa dữ liệu mà em phải sử dụng khi thực hiện những Instructions này. Anh sẽ viết vào mảnh giấy kế tiếp những gì anh cần em làm [Request] giúp anh và xếp chúng lại thành chồng [stack them up].

Khi anh hoàn tất việc xếp chúng lại, anh sẽ báo để em đọc chồng giấy này [stack of papers]. Em lấy Tờ Đầu Tiên ra khỏi chồng xếp và thực hiện theo các Requests của anh. Sau đó tờ kế tiếp cũng tương tự, em thực hiện các Request đó.

Em sẽ tiếp tục làm điều này cho đến khi em đến dưới cùng Stack, dưới cùng chồng giấy, nơi chứa Return Pointer của anh. Em nhìn vào Return Pointer này [đó là Memory Address của anh] để biết nơi em sẽ gửi kết quả về tất cả Instructions mà anh đã yêu cầu em thực hiện.

Điều này có thể được ánh xạ tương quan đến sự giao tiếp của các Processes khác nhau và CPU. Một Process sẽ Stack Up [xếp chồng] thông tin mà nó cần để giao tiếp với CPU. CPU phải keep track - theo dõi vị trí Process này bên trong Stack, đó là mục đích của Stack Pointer. Sau khi item đầu tiên được thực thi, thì Stack Pointer sẽ di chuyển xuống [moves down] để báo cho CPU biết vị trí phần tiếp theo [next piece] của dữ liệu nằm ở đâu.

Program Status Word - PSW nắm giữ các Condition Bits khác nhau. Một trong các Bits sẽ cho biết liệu CPU nên hoạt động trong chế độ User Mode [còn gọi là Problem State] hay hoạt động trong chế độ Privileged Mode [hay còn gọi là Kernel hoặc Supervisor Mode]. Điểm mấu chốt của chương này là dạy cho chúng ta biết cách Hệ Điều Hành tự bảo vệ chính bản thân nó.

Hệ Điều Hành cần bảo vệ chính bản thân nó đối với các Applications, Utilities và User Activities. Nếu nó muốn cung cấp một môi trường State & Safe. Một trong các cơ chế bảo vệ này được thực hiện thông qua việc sử dụng Different Execution Modes - Các chế độ thực thi khác nhau.

Khi một Application cần CPU thực hiện các Instructions của nó, CPU sẽ hoạt động trong chế độ User Mode. Đây là chế độ có Lower Privilege Level - Mức độ đặc quyền thấp, nhiều Instructions và Function của CPU sẽ không Available đối với các requests từ phía Application khi hoạt động trong chế độ này.

Lý do phải cẩn thận như thế, là bởi vì các nhà phát triển Hệ Điều Hành "không biết" mấy ông phát triển Application là ai, hoặc họ có mưu đồ phá rối gì hay không, cho nên tốt nhất là để CPU hoạt động trong chế độ Lower Privileged khi thực thi các loại Instructions từ Application.

Lấy một ví dụ đơn giản dễ hiểu cho quần chúng nhân dân được rõ, nếu chúng ta dự kiến rằng khách đến chơi nhà sẽ mang theo những cô cậu bé con 2 3 tuổi, chúng ta thường sẽ "di dời" hết tất cả những thứ dễ vỡ ra xa khỏi phòng khách. Không một ai biết chắc được các bé con 2 3 tuổi sẽ làm điều gì, nhưng chúng thường sẽ kiếm một cái gì đó để phá vỡ hoặc tò mò nghịch ngợm cho vui.

Hệ Điều Hành và CPU cũng vậy, chúng không chắc các Applications sẽ làm những trò "điên rồ" gì, cho nên đó là lý do tại sao việc thực thi Applications lại nằm trong chế độ Lower Privilege.

Nếu PSW có Bit Value cho biết các Instructions cần được thực hiện trong chế độ Privileged Mode, thì điều này có nghĩa đó là một Trusted Process - Tiến trình đáng tin cậy [Operating System Process], nó có thể thực hiện Request và Access vào những function mà không available trong chế độ User Mode. Ví dụ, nó sẽ xảy ra nếu Hệ Điều Hành cần tương tác với một thiết bị ngoại vi, đây là Privileged Activity mà các applications không thể nào thực hiện được.

Khi những loại Instructions này được truyền đến CPU, về cơ bản PSW sẽ "nói" với CPU rằng : "Process thực hiện yêu cầu này là một anh chàng có tất cả quyền hạn. Chúng ta hãy tin tưởng anh ta. Tiến lên và thực hiện công việc này cho anh ta đi nào."

Memory Addresses của các Instructions và Data có thể được xử lý, sẽ được lưu trữ trong Registers cho đến khi CPU cần dùng đến. CPU được kết nối đến Address Bus, đó là Hardwired Connection - Một kết nối phần cứng đến RAM Chips trong hệ thống và các thiết bị Input/Output.

Memory được "xắt" nhỏ ra thành nhiều phần có các Individual Addresses - Địa chỉ cá nhân được liên kết với chúng. I/O Devices bao gồm : CD-ROM, USB Device, Hard Drive, Floppy Drive, vân vân... cũng được cấp Specific Unique Addresses - Địa chỉ cụ thể duy nhất. Nếu CPU cần truy cập một số Data đến từ Memory hoặc từ các thiết bị I/O, nó sẽ gửi xuống các Address thuộc về nơi mà Data cần được Located.

Circuitry - Những Vi mạch gắn liền với Memory hoặc các thiết bị I/O sẽ nhận biết Address mà CPU đã gửi xuống Address Bus và hướng dẫn cho Memory hoặc I/O Devices đọc các Data đã được yêu cầu và đặt nó lên Data Bus.

Tóm gọn lại, Address Bus được sử dụng bởi CPU để chỉ ra vị trí các Instructions có thể được xử lý, Memory hoặc các thiết bị I/O sẽ response bằng cách gửi Data thông qua Data Bus. Tiến trình này được minh họa trong Figure 5-3.

Sau khi CPU đã thực hiện xong việc tính toán [computation] của nó, nó cần phải trả lại kết quả đến Memory của Requesting Program. CPU sẽ gửi Address của Requesting Program xuống Data Bus với command WRITE. Những dữ liệu này khi đó sẽ được Written xuống Memory Space của Requesting Program.

Address và Data Buses có thể là 8, 16, 32 hoặc 64 bits. Hầu hết các hệ thống ngày nay đều sử dụng 32-bit Address Bus, nghĩa là hệ thống có Address Space khá lớn [2^32]. Hệ thống cũng có thể có 32-bit Data Bus, nghĩa là hệ thống có thể di chuyển Data song song qua lại giữa Memory, I/O Devices và CPU.. [32-bit Data Bus nghĩa là kích thước của các khối dữ liệu - Data Chunks mà CPU có thể request tại một thời điểm là 32-bit.]

Multiprocessing

Một số máy tính đặc biệt có nhiều hơn 1 CPU, mục đích là để tăng hiệu suất hoạt động. Hệ Điều Hành cần phải được phát triển đặc biệt để có thể hiểu và làm việc với nhiều hơn 1 Processor - Bộ Vi Xử Lý.

Nếu hệ thống máy tính được cấu hình để làm việc trong chế độ Symmetric Mode - Chế Độ Đối Xứng, thì điều này có nghĩa các Processors sẽ được "giao" cho công việc khi cần thiết, chẳng hạn như CPU 1 & CPU 2 trong Figure 5-4. Nó giống như một môi trường Load-balancing.

Khi một Process cần Instructions để thực thi, Scheduler sẽ xác định xem Processor nào sẽ thực hiện công việc này và gửi nó đến cho processor đó. Nếu một Processor được dành riêng cho một công việc hoặc một application cụ thể, thì tất cả các application khác sẽ chạy trên một Processor khác.

Trong Figure 5-4, CPU 4 được Dedicated - Dành riêng cho một Application và các Threads của nó, trong khi đó CPU 3 được sử dụng bởi Hệ Điều Hành. Khi một Processor được sử dụng Dedicated như trong ví dụ này, thì có nghĩa hệ thống đang hoạt động trong chế độ Asymmetric Mode - Chế Độ Bất Đối Xứng.

Operating System Architecture

Operating System - Hệ Điều Hành [HĐH] cung cấp môi trường cho Applications và Users làm việc bên trong nó. Tất cả các HĐH đều được xem như một loài động vật phức tạp, được tạo nên từ nhiều Layers và các Modules chức năng khác nhau. HĐH có trách nhiệm quản lý các thành phần Hardware, quản lý Memory, I/O Operations, File System, quản lý Process và cung cấp System Services. Chúng ta sẽ bàn luận về những chủ đề này ở phần kế tiếp.

Tuy nhiên bạn phải nhận thức được rằng, các cuộc thảo luận trong cuốn sách này chỉ mang tính chuyên đề, hiểu rộng chứ không đòi hỏi hiểu sâu.

Process Management - Quản lý Process

HĐH, Utilities - Các tiện ích và các Applications trong thực tế chỉ là Lines & Line of Instructions. Chúng là những Static Lines of Code - Những dòng mã tĩnh lặng, được mang đến cho cuộc sống khi chúng được tạo ra và được đưa vào Memory. Applications hoạt động như một Individual Units - Đơn vị độc lập, được gọi là Processes. HĐH có những Processes khác nhau thực hiện các loại chức năng khác nhau.

Process là một Set of Instructions - Tập hợp các chỉ thị thực sự Running. Program sẽ không được xem là một Process cho đến khi nó được nạp vào Memory và được kích hoạt bởi HĐH. Khi một Process được tạo ra, HĐH sẽ gán các resources cho nó, chẳng hạn như Memory Segment, CPU Time Slot, truy cập vào System Application Programming Interfaces - Giao Diện Lập Trình Ứng Dụng Hệ Thống [API] và các Files cho mục đích tương tác.

Collection of the Instructions và các Resources được giao còn được gọi là một Process.

HĐH có khá nhiều Processes, được sử dụng để cung cấp và duy trì môi trường cho Applications và Users hoạt động bên trong nó. Một số ví dụ về những chức năng mà các Processes cung cấp, bao gồm : hiển thị Data lên màn hình, Spooling print jobs và save data vào Temporary Files.

Các HĐH ngày nay cung cấp MultiProgramming, nghĩa là nhiều hơn một Program [hoặc Process] có thể được nạp vào trong Memory tại cùng một thời điểm. Điều này cho phép chúng ta vừa chạy Antivirus Software, Word, vừa chạy Personal Firewall và E-mail Client cùng một lúc.

Mỗi Applications này có thể chạy 1 hoặc nhiều Processes.Chú ý : Nhiều HĐH ngày nay cung cấp khả năng Multiprogramming & Multitasking. Điều này đúng, tuy nhiên Multiprogramming chỉ là HĐH có thể nạp [load] nhiều hơn một Application vào Memory cùng một lúc. Nhưng trong thực tế, Multiproramming đã được thay thế bởi Multitasking - Đa Nhiệm, nghĩa là nhiều hơn một Application có thể được nạp vào Memory cùng một lúc và HĐH có thể giải quyết các Requests đến từ các Applications khác nhau này cùng một lúc, trong khi đó Multiprogramming thì không thể.

[Tham khảo thêm //wiki.answers.com/Q/What_are_the_differences_between_multitasking_and_multiprogramming

ixzz1heUikQ31]

Trước đây, HĐH đã lãng phí quá nhiều nguồn tài nguyên quý giá nhất của chúng : CPU Time.

Ví dụ, khi một trình xử lý văn bản - word processor yêu cầu mở một File trên ổ đĩa mềm, CPU sẽ gửi request đến ổ đĩa mềm và chờ ổ đĩa mềm Initialize - Khởi động, chờ cho đầu đọc [head] tìm đúng Track và Sector, cuối cùng là chờ ổ đĩa mềm gửi Data thông qua Data Bus đến CPU để xử lý. Mỗi khoảng chờ này làm lãng phí quá nhiều thời gian cho CPU.

Để tránh việc lãng phí CPU Time, Multitasking đã được phát triển, nó cho phép nhiều hơn một chương trình được nạp vào Memory tại một thời điểm. Thay vì nhàn rỗi ngồi chờ các hoạt động từ 1 Process, CPU có thể dành thời gian đó để thực thi Instructions của những Processes khác, giúp đẩy mạnh tốc độ xử lý cho tất cả các Processes khác nhau.

Ví dụ một câu chuyện đời thường cho dễ hình dung, nếu chúng ta [CPU] đặt bánh mì vào trong lò nướng bánh [Process] và chỉ đứng yên đó để chờ lò nướng kết thúc công việc của nó, thì có nghĩa chúng ta đang lãng phí thời gian của chính bản thân mình.

Thay vào đó, nếu chúng ta đặt bánh vào lò nướng, trong thời gian chờ đợi ta vừa pha cà phê, vừa duyệt tin tức và nghĩ ra một chiến lược mới trong việc trốn vợ đi nhậu cuối tuần, thì có nghĩa ta đang tận dụng được thời gian một cách hiệu quả, không lãng phí.

Các HĐH thuở ban đầu hoạt động dưới dạng Cooperative Multitasking - Đa Nhiệm Hợp Tác, sau đó phát triển thành Preemptive Multitasking - Đa Nhiệm Ưu Tiên.

Cooperative Multitasking - Đa Nhiệm Hợp Tác được sử dụng trong Windows 286, Windows 3.x và các hệ thống Macintosh thuở ban đầu, đòi hỏi các Processes phải Voluntarity Release Resources - Tự giác giải phóng tài nguyên mà chúng đang sử dụng.

Điều này không mang lại một môi trường ổn định, bởi vì nếu như có một gã lập trình viên nào đó viết mã chương trình của anh ta không chính xác trong việc giải phóng tài nguyên khi chương trình được sử dụng hoàn tất, thì tài nguyên sẽ bị Giam giữ vô thời hạn - Committed Indefinitely, do đó sẽ không sẵn sàng phục vụ cho các Processes khác.

Preemptive Multitasking - Đa Nhiệm Ưu Tiên được sử dụng trong Windows 9.x, NT, 2000, XP và các hệ thống Unix. HĐH sẽ kiểm soát quá trình thời gian mà một Process có thể sử dụng tài nguyên. HĐH có thể Suspend - Tạm ngừng việc sử dụng CPU của một Process và cho phép một Process khác truy cập vào nó, thông qua việc sử dụng Time Sharing - Chia sẻ thời gian.

Vậy cho nên đối với các HĐH sử dụng Cooperative Multitasking, Processes kiểm soát quá nhiều so với việc giải phóng tài nguyên và khi một Application bị treo, nó thường ảnh hưởng luôn đến tất cả các Applications khác, đôi khi ảnh hưởng lên cả chính bản thân HĐH. Đối với các HĐH sử dụng Preemptive Multitasking, khi một Application bị treo cũng sẽ không dễ dàng gì gây ảnh hưởng tiêu cực đến các Applications khác.

Các HĐH khác nhau làm việc trong các Process Models khác nhau. Ví dụ, HĐH Unix & Linux cho phép Process của chúng tạo ra các Children Processes mới, thường được gọi là Forking.

Giả sử chúng ta đang làm việc bên trong Shell của một hệ thống Linux. Shell được diễn dịch bằng command, thông qua giao diện Console cho phép người dùng tương tác với HĐH. Shell vận hành như một Process. Khi chúng ta gõ vào Shell lệnh :

cat file1 file2 | grep ducnguyena

Chúng ta đang "nói" với HĐH rằng, hãy Concatenate [CAT] - Nối 2 files này lại với nhau, sau đó Search [GREP] các dòng có giá trị là ducnguyena bên trong chúng. Khi chúng ta ấn phím ENTER, sẽ có Shell Forks Two Children Processes - 2 Processes "con" phân nhánh từ Shell Process được tạo ra, một dành cho command CAT và một dành cho command GREP.

Mỗi Children Processes này đều sẽ mang các Characteristics - Đặc Điểm của Parent Process, nhưng nó cũng có memory space, stack và program counter values của riêng nó.

Process có thể vận hành trong trạng thái Running State [CPU đang thực thi các Instructions và Data của nó], Ready State [đang chờ để gửi Instructions đến CPU] hoặc Blocked State [Đang chờ Input Data, chẳng hạn như keystrokes từ User].

Các trạng thái khác nhau này được minh họa trong Figure 5-5.

Khi một Process bị Blocked, nghĩa là nó đang chờ đợi Data nào đó gửi đến nó. Trong ví dụ trên, khi chúng ta gõ command : cat file 1 file 2 | grep ducnguyena , thì Grep Process thực sự sẽ không thể nào thực hiện được chức năng tìm kiếm của nó, cho đến khi Cat Process [process đầu tiên] hoàn tất việc nối 2 files lại với nhau.

Grep Process sẽ tự đưa chính bản thân nó vào chế độ Sleep trong trạng thái Blocked State cho đến khi Cat Process hoàn tất và gửi cho Grep Process dữ liệu đầu vào [input data] của nó, để Grep Process thực hiện công việc tìm kiếm.

Chú ý : Không phải HĐH nào cũng kiến tạo và vận hành Process hierarchy giống như Unix & Linux. HĐH Windows không Fork - Phân nhánh ra các Children Process mới, mà nó thay bằng Threads, hoạt động tương tự như Fork trong bối cảnh của Parent Process. Điều này đi sâu hơn những gì chúng ta cần biết cho kỳ thi CISSP, nhưng cuộc sống này không chỉ có kỳ thi CISSP đúng không ? Nếu có cơ hội hãy tìm hiểu nhé các bạn.

HĐH có trách nhiệm tạo ra New Processes, gán resources cho chúng, đồng bộ hóa Communication của chúng, và đảm bảo không có bất kỳ điều gì Non-secure đang diễn ra.

HĐH nắm giữ Process Table, trong đó có 1 Entry cho mỗi Process. Table này chứa State của Process, Stack Pointer, Memory Allocation, Program Counter và Status của các Open Files được sử dụng. Lý do HĐH documents lại tất cả các Status Information là bởi CPU cần nạp tất cả những thứ này vào Registers của nó khi nó cần tương tác với chúng.

Ví dụ Process 1, khi CPU Time Slide của Process 1 qua đi, tất cả Status Information hiện tại của Process 1 sẽ được lưu trong Process Table để khi Time Slice của nó open again, tất cả Status Information này có thể được đưa trở lại CPU Registers.

Khi CPU Time của Process 2 diễn ra, thông tin Status của nó sẽ được chuyển từ Process Table đến CPU Registers và chuyển ngược trở về khi Time Slide qua đi. Các bước này được minh họa trong Figure 5-6

Làm thế nào để Process biết được khi nào nó có thể communication - giao tiếp với CPU ? Điều này được thực hiện bằng cách sử dụng Interrupts - Ngắt. HĐH đã "đánh lừa" chúng ta và Applications, khiến chúng ta nghĩ rằng nó và CPU có thể thực hiện đồng thời tất cả các nhiệm vụ cùng một lúc. Trong thực tế, điều này là không thể.

Hầu hết các CPUs chỉ có thể thực hiện một điều tại một thời điểm. Cho nên HĐH có Hardware Interrupts và Software Interrupts. Khi một thiết bị cần communicate với CPU, nó phải chờ việc Interrupt diễn ra xong thì mới được giao tiếp.

Khi Process tương tác với CPU và việc Interrupt diễn ra [khi có một process khác đã gửi request truy cập đến CPU], thông tin của Process hiện hành sẽ được lưu lại vào trong Process Table, và Process tiếp theo sẽ tương tác với CPU.

Chú ý : Một số Critical Processes sẽ "không thể" bị Interrupted bởi một Process khác. HĐH chịu trách nhiệm trong việc thiết lập Priorities cho các Proceses khác nhau. Khi có một Process cần Interrupt một process khác, HĐH sẽ so sánh mức độ Priority của hai Processes để xác định xem việc Interruption có được phép hay không.

Có hai loại Interrupts - Ngắt : là Maskable và Non-Maskable

Maskable Interrupt [MI] - Khi yêu cầu ngắt thì có hai khả năng xảy ra :

1. Được ngắt nếu ngắt đó ở trạng thái cho phép 2. Không được ngắt nếu ngắt đó ở trạng thái bị Blocked

MI được chỉ định đến một Event có thể không quá quan trọng, lập trình viên có thể chỉ ra rằng nếu có các cuộc Interrupts dạng MI diễn ra, ứng dụng cũng sẽ không dừng lại bất kỳ những gì nó đang làm. Có nghĩa là Interrupt này bị bỏ qua.

Non-Maskable Interrupt [NMI] - Có yêu cầu ngắt thì bắt buộc phải ngắt ngay lập tức.

Non-Maskable Interrupts không bao giờ bị overridden bởi một Application nào cả, bởi vì nó là Event có loại Interrupt được chỉ định là Critical. Ví dụ, Reset Button được chỉ định là Non-Maskable Interrupt. Có nghĩa khi chúng ta bấm vào nút này, CPU sẽ thực thi các Instructions của nó ngay lập tức !

Ví dụ, Maskable Interrupts các thiết bị phổ biến như Disk/Network Adapters có thể bị Blocked bởi CPU. Non-Maskable Interrupts như việc mất điện không thể nào bị Blocked bởi CPU.

Watchdog Timer là một ví dụ về Critical Process mà luôn luôn phải được vận hành. Process này sẽ Reset lại hệ thống với Warm Boot nếu HĐH bị treo và không thể khôi phục lại chính bản thân nó. Ví dụ, nếu có problem về Memory Management và HĐH bị treo, Watchdog Timer sẽ tiến hành reset hệ thống. Đây là một trong các cơ chế để đảm bảo việc Software cung cấp một môi trường Stable hơn.

Thread Management

Như đã mô tả trước đây, Process là một Program đã được nạp vào trong Memory. Nói chính xác hơn, Process là các Instructions của Program và tất cả các Resources được gán cho Process bởi HĐH. Nói dễ hiểu hơn nữa, nó nhóm tất cả các Instructions và Resources này lại với nhau và kiểm soát chúng như 1 thực thể duy nhất, ta gọi đó là Process.

Khi Process cần gửi một cái gì đó đến cho CPU để xử lý, nó sẽ tạo ra Thread. Thread được tạo nên từ tập hợp Instruction & Data cần được xử lý bởi CPU. Hầu hết các Applications đều có một số chức năng khác nhau.

Word - Chương trình xử lý văn bản có thể mở Files, lưu Files, mở một chương trình khác [chẳng hạn như E-mail client], in ấn Documents. Mỗi một chức năng này đều yêu cầu một Thread [instruction set], có thể được tạo ra tự động.

Ví dụ, nếu anh Tèo Thợ Xây chọn in Document của anh ta, chương trình xử lý văn bản sẽ tạo ra một Thread có chứa Instructions về cách in Document này, cần in nó như thế nào [font, màu sắc, kiểu chữ, vân vân]. Nếu anh Tèo chọn gửi Document qua Email thông qua chương trình xử lý văn bản, một Thread khác sẽ được tạo ra để thông báo mở chương trình Email Client và cho biết File nào cần được gửi đi.

Threads tự động được tạo ra và cũng tự động bị phá hủy khi cần thiết. Sau khi cu Tèo đã hoàn tất việc in ấn, Thread được tạo ra cho chức năng in ấn sẽ tự động bị phá hủy đi.

Program - Chương trình đã được phát triển để thực hiện các nhiệm vụ khác nhau tại một thời điểm, có Capatable - Khả năng vận hành các Threads khác nhau cùng một lúc. Application có khả năng này còn được gọi là Multithreaded Application.Chú ý : Mỗi Thread đều chia sẻ cùng các Resources của Process đã tạo ra nó. Vì vậy cho nên, tất cả các Threads được tạo ra bởi chương trình xử lý văn bản sẽ hoạt động cùng trong một Memory Space và có quyền truy cập đến tất cả các Files và System Resources như Process xử lý văn bản.

Process Scheduling

Scheduling & Synchronizing các Processes khác nhau và các hoạt động của chúng chính là một phần trong việc Process Management, đó là trách nhiệm của Hệ Điều Hành. Một số thành phần cần phải được xem xét đến trong lúc phát triển HĐH, điều đó sẽ chỉ ra cho thấy Process Scheduling sẽ diễn ra như thế nào.

Scheduling Policy được tạo ra để quản lý việc tương tác của các Threads với nhau. Các HĐH khác nhau có thể sử dụng Schedulers khác nhau, về cơ bản đó là các Algorithms - Thuật toán kiểm soát TimeSharing của CPU.

Như đã nói qua trước đây, các Processes khác nhau sẽ được gán mức độ Priority khác nhau [Interrupts], điều đó sẽ cho chúng ta biết được Processes nào có thể "thủ tiêu" Processes nào, khi đòi hỏi CPU Time Allocation.

Hệ Điều Hành tạo ra và xóa các Processes khi cần thiết, giám sát sự thay đổi State của chúng [Ready, Blocked, Running]. Hệ Điều Hành cũng chịu trách nhiệm cho việc kiểm soát Deadlocks giữa các Processes sử dụng cùng Resources.

Khi có một Process đưa ra yêu cầu đến một Resource như : Memory Allocation, Printer, Secondary Storage Devices, Disk Space, vân vân... Hệ Điều Hành sẽ tạo ra các Data Structures và dành nó cho các Processes cần thiết để hoạt động này được hoàn thành.

Sau khi hoạt động này diễn ra hoàn tất [tài liệu đã được in, file đã được saved], Process cần phải hủy các Data Structures đã được xây dựng và giải phóng các Resources trở về Resource pool, để chúng available cho những Processes khác. Nếu điều này không diễn ra đúng cách, hệ thống có thể gặp phải tình huống cạn kiệt Critical Resources [như Memory chẳng hạn].

Một tình trạng khác cần phải được quan tâm đến là Software Deadlock - "Bế Tắc" Phần Mềm.

Một ví dụ về tình trạng Deadlock : khi process A đang "tạm giam" resource 1 và cần sử dụng resource 2 để hoàn thành nhiệm vụ của nó, nhưng process B lại đang "tạm giam" resource 2 và cần resource 1 để kết thúc công việc của nó. Vì vậy cả hai Processes đều rơi vào trong Deadlock - Bế Tắc, bởi vì chúng không có Resources mà chúng cần để hoàn tất nhiệm vụ của chúng.

Các HĐHs ngày nay đều đã có trí thông minh để phát hiện ra tình huống này, một trong hai hoặc cả hai Processes sẽ được giải phóng các Resources mà chúng đang "tạm giam - committed", hoặc HĐH sẽ kiểm soát việc phân bổ - allocation Resources để có sự chia sẻ hợp lý giữa các Processess.

Các HĐHs có những phương pháp khác nhau để xử lý Resource requests, giải phóng & giải quyết vấn đề tình huống Deadlock.

Trong một số hệ thống, nếu một Resource đã được yêu cầu [requested] hiện Unavailable trong một thời điểm nào đó, HĐH sẽ "kills" Process đang "giam giữ" Resource đó. Hành động này sẽ giải phóng Resource khỏi Process đang giam giữ nó và Restart lại Process, để nó "clean" và Available cho các Processes khác sử dụng.

Có những HĐHs khác sẽ sử dụng phương pháp như sau : đòi hỏi Program request hết tất cả [all] các Resources mà nó cần trước khi nó thực sự bắt đầu thực thi Instructions, hoặc đòi hỏi Program phải giải phóng Resources mà nó đang giam giữ trước khi nó có thể sở hữu nhiều hơn.

Process Activity

Các máy tính có thể chạy nhiều Applications và Processes khác nhau cùng một lúc. Các Processes phải chia sẻ Resources và "chơi đẹp" với nhau để đảm bảo một môi trường máy tính Stable và Safe, duy trì tính toàn vẹn của nó. Một số Data Files, Memory và Variables thực sự đã được chia sẻ - shared giữa các Processes khác nhau.

Điều quan trọng là nhiều hơn một Process không được cố gắng Read & Write những hạng mục này tại cùng một thời điểm.

Hệ Điều Hành là Master Program sẽ ngăn chặn điều trên xảy ra và chịu trách nhiệm đảm bảo các Programs không làm hỏng hóc Data của nhau trong Memory. HĐH hoạt động với CPU cung cấp Time Slicing - Phân chia thời gian, thông qua việc sử dụng các Interrupts để đảm bảo rằng các Processes được tiếp cận thích đáng đến CPU.

Điều này cũng giúp cho một số Critical System Functions không bị ảnh hưởng tiêu cực bởi các Rogue Applications - Ứng dụng giả mạo.

Để bảo vệ các Processes, HĐHs có thể sử dụng Process Isolation - Cô lập tiến trình.

Process Isolation - Cô lập tiến trình, là điều cần thiết để đảm bảo rằng các Processes không "dẫm đạp lên nhau", giao tiếp theo cách không an toàn hoặc gây ảnh hưởng tiêu cực đến năng suất của processes khác. Các HĐH cũ trước đây đã không thực thi Process Isolation như các HĐH ngày nay.

Đây là lý do tại sao trong các HĐHs cũ, khi một trong các chương trình bị treo, tất cả các chương trình còn lại, đôi khi là chính bản thân HĐH cũng sẽ bị treo theo luôn.

Với Process Isolation, nếu có 1 Process bị treo vì một lý do nào đó, nó sẽ không gây ảnh hưởng đến các Processes khác đang vận hành. Process Isolation là điều cần thiết đối với Preemptive Multitasking - Đa Nhiệm Ưu Tiên. Các phương pháp khác nhau sau đây có thể được sử dụng để tiến hành Process Isolation :

• Encapsulation of objects : "Đóng gói" các đối tượng. • Time multiplexing of shared resources : Ghép kênh thời gian các Resources được chia sẻ • Naming distinctions : Đặt tên phân biệt. • Virtual mapping : Ánh xạ ảo

Khi một Process được Encapsulated - Đóng gói, có nghĩa là sẽ không có bất kỳ Process nào khác có thể "hiểu" hoặc tương tác với Internal Programming Code - Mã lập trình cục bộ của nó. Khi Process A cần giao tiếp với Process B, Process A chỉ cần biết cách giao tiếp với Interface của Process B. Interface sẽ xác định cách giao tiếp cần diễn ra giữa hai Processes.

Một ví dụ trong đời sống thực cho dễ hiểu, làm thế nào bạn có thể giao tiếp với một ông khách hàng khó tính ? Bạn phải gọi ông ta là Mr, luôn miệng nói Please và Thank You, nói chuyện một cách tôn trọng để đạt được bất kỳ điều gì bạn muốn.

Điều này cũng tương tự đúng với các Software Components khi chúng cần giao tiếp với nhau. Chúng bắt buộc phải biết cách làm thế nào để giao tiếp thích hợp với Interfaces của nhau. Interfaces chỉ ra các loại Requests mà một Process sẽ chấp nhận [accept] và loại Output sẽ được cung cấp.

Cho nên hai Processes có thể giao tiếp với nhau, ngay cả khi chúng được lập trình bằng những ngôn ngữ khác nhau, miễn là chúng biết cách giao tiếp với Interface của nhau.

Encapsulation cung cấp khả năng Data Hiding - Che giấu dữ liệu, nghĩa là các Software Components bên ngoài [Outside] sẽ không biết cách hoạt động của Process và sẽ không thể nào thao tác Internal Code của Process. Đây là cơ chế Integrity và thực thi Modularity - Tính Mô Đul trong việc lập trình mã.

Time Multiplexing - Ghép kênh thời gian, là công nghệ cho phép các Processes cùng sử dụng chung Resources. Như đã nói qua trước đây, CPU bắt buộc phải được Shared giữa các Processes với nhau. Mặc dù trông có vẻ như tất cả các Applications đều đang Running cùng một lúc [đang executing Instructions của chúng], nhưng thực tế HĐH đang Splitting - Phân chia thời gian sử dụng giữa các Process.

Multiplexing nghĩa là có một số Data Sources và Individual Data Pieces được ghép vào cùng một Communication Channel - Kênh giao tiếp.

Trong trường hợp này, HĐH sẽ điều phối - coordinating các Requests khác nhau từ các Processes khác nhau và ghép chúng xuyên qua một CPU shared. HĐH bắt buộc phải cung cấp Time Multiplexing thích hợp [resource sharing - chia sẻ tài nguyên], để đảm bảo một môi trường hoạt động ổn định cho Software và Users.

Naming Distinctions - Đặt tên phân biệt, nghĩa là các Processes khác nhau sẽ có tên gọi riêng của chúng [own name] hoặc có Identification Value - Giá trị Nhận Diện. Các Processes thông thường sẽ được gán giá trị Process Identification Value, HĐH và các Processes khác sẽ sử dụng để gọi đến chúng. Nếu mỗi Process được cô lập - Isolated, điều đó có nghĩa mỗi Process sẽ có một giá trị PID độc nhất.

Virtual Address Space Mapping có sự khác biệt với Physical Mapping của Memory. Một Application được viết ra về cơ bản nó nghĩ rằng nó chỉ là Program running trên một HĐH. Khi Application cần Memory để làm việc, nó sẽ nói với Memory Manager của HĐH nó cần bao nhiêu Memory. HĐH sẽ Carves - Cắt ra một số lượng Memory và gán nó cho Application.

Application sử dụng Own Address Scheme của riêng nó, thường bắt đầu từ 0. Nhưng trong thực tế, Application không làm việc với Physical Address Space như nó nghĩ ! Thay vào đó, Application làm việc trong Address Space mà Memory Manager đã cấp phát cho nó. Physical Memory chính là RAM Chips trong hệ thống. HĐH sẽ phân cắt Memory này và gán các phần của nó cho những sự đòi hỏi đến từ phía mấy "ông" Processes.

Sau khi Process đã được gán Own Memory Space - Không gian bộ nhớ của riêng nó, nó có thể sử dụng phần Address này, đây được gọi là Virtual Address Mapping. Virtual Address Mapping - Ánh xạ địa chỉ ảo cho phép các Processes khác nhau sở hữu Memory Space của riêng nó.

Memory Manager đảm bảo không có Processes nào tương tác không đúng với Memory của Process khác. Điều này cung cấp tính toàn vẹn - Intergrity và tính bảo mật - Confidentiality.

Memory Management

Để cung cấp một môi trường ổn định và an toàn, HĐH bắt buộc phải thực hiện Memory Management đúng cách, nó là một trong những nhiệm vụ quan trọng nhất. Tất cả đều xảy ra trong Memory. Nó tương tự như việc chúng ta phụ thuộc vào khí Oxy và Trọng Lực cho sự tồn tại của chúng ta. Nếu một trong hai thứ bị mất cân bằng, chúng ta đang gặp rắc rối lớn rồi đấy !

Mục đích [goals] của Memory Management - Quản lý bộ nhớ :

• Cung cấp Abstraction Level - Mức độ trừu tượng cho các lập trình viên. • Tối đa hóa performance bằng việc Limited - Hạn chế số lượng Memory sẵn có [available]. • Bảo vệ HĐH và các Applications được nạp vào trong Memory.

Abstraction - Trừu tượng, có nghĩa là Details - Chi tiết của một điều gì đó Hidden - ẩn.

Các nhà phát triển Application thường không biết số lượng hoặc loại Memory available trong mỗi hệ thống mà Code của họ sẽ được nạp vào. Nếu một nhà phát triển nào đó quan tâm đến loại Detail này, thì Application của anh ta khi đó sẽ hoạt động chỉ trên 1 hệ thống duy nhất, ánh xạ đến tất cả các chi tiết kỹ thuật - specifications của anh ta.

Để cho phép tính di động - Portability, Memory Manager ẩn hết tất cả các Memory issues và chỉ cung cấp cho Application một Memory Segment.

Mỗi máy tính đều có Memory Hierarchy - Hệ thống phân cấp Bộ Nhớ. Một số lượng nhỏ Memory rất nhanh và rất đắt tiền [Registers, Cache], trong khi đó một số lượng lớn lại chậm hơn và rẻ hơn [RAM, Hard Drive]. Một phần của HĐH sẽ chịu trách nhiệm theo dõi cách các loại Memory khác nhau này được sử dụng ra làm sao, ta gọi là Memory Manager.

Công việc của Memory Manager là allocate - Phân bổ và deallocate - Giải Phóng các Memory Segments khác nhau, thực thi Access Control để đảm bảo các Processes chỉ tương tác với chính Memory Segments của riêng chúng, và kiểm soát Swap Memory Contents từ RAM đến Hard Drive.

Memory Manager có 5 trách nhiệm cơ bản sau :

Relocation

• Swap contents - Trao đổi nội dung từ RAM đến Hard Drive [ổ cứng] khi cần thiết. [sẽ được giải thích trong phần Virtual Memory]. • Cung cấp Pointers cho các Applications, nếu Instructions và Memory Segment của chúng được di dời sang vị trí khác trong Main Memory - Bộ nhớ chính.

Protection

• Limit - Giới hạn sự tương tác của các Processes, chỉ cho phép chúng được tương tác với những Memory Segments được phân bổ cho riêng chúng. • Cung cấp Access Control đến Memory Segments.

Sharing

• Sử dụng Complex Controls - Kiểm soát phức tạp để đảm bảo Intergrity và Confidentiality, khi các Processes cần sử dụng cùng một Memory Segments được shared. • Cho phép nhiều Users có các mức độ truy cập khác nhau, tương tác cùng một Application đang vận hành trong một Memory Segment.

Logical organization

• Cho phép sharing các Software Modules cụ thể, chẳng hạn như Dynamic Link Library [DDL] procedures.

Physical organization

• Segment - Phân đoạn Physical Memory Space cho Application và các Processes của HĐH.

Chú ý : Dynamic Link Library [DLL] là một tập hợp những Functions mà các Appplications có thể gọi đến để thực hiện các loại Procedures khác nhau. Ví dụ, HĐH Windows có crypt32.dll được sử dụng bởi HĐH và các Applications cho chức năng Mã Hóa. Windows có một tập hợp các DLLs, đó là một thư viện các chức năng để gọi đến khi cần thiết.

Làm thế nào HĐH có thể đảm bảo một Process chỉ tương tác với Memory Segment của riêng nó ? Khi Process tạo ra Thread, bởi vì nó cần xử lý một số Instructions & Data, CPU sẽ sử dụng 2 Registers. Chính là Base Register và Limit Register.

Base Register chứa Beginning Address - Địa chỉ bắt đầu đã được gán cho Process và Limit Register chứa Ending Address - Địa chỉ kết thúc, được minh họa trong Figure 5-7.

Thread chứa Address nơi mà Instruction và Data cần phải được xử lý. CPU sẽ so sánh Address này với Base và Limit Registers để đảm bảo Thread không "trying - cố gắng" truy cập vào Memory Segment outside of its bound - nằm ngoài giới hạn của nó.

Memory còn được bảo vệ thông qua việc sử dụng User Mode và Privileged Mode, đã được đề cập trước đây và sẽ được đề cập chi tiết hơn ở phần sau "CPU Modes & Protections Ring".

Memory Types

OS Instructions, Applications và Data được lưu trữ trong Memory, nhưng những thứ như BISO, Device Controller Instructions & Firmware. Không phải tất cả bọn chúng đều "cư ngụ" trong cùng một Memory Location hoặc thậm chí là trong cùng một Memory.

Các loại Memory khác nhau, những gì đang sử dụng chúng và làm thế nào để truy cập đến chúng có thể hơi rắc rối lộn xộn, bởi vì CPU phải xử lý với nhiều loại khác nhau cho những mục đích khác nhau.

Những phần sau đây sẽ vạch ra các loại Memory khác nhau có thể được sử dụng bên trong các hệ thống máy tính.

Random Access Memory

Random Access Memory - RAM là loại thiết bị Temporary Storage - Lưu trữ tạm thời, nơi mà Data và Program Instructions có thể tạm thời được lưu trữ và được sửa đổi [altered]. Nó được sử dụng cho các hoạt động Read/Write bởi HĐH và Applications. Nó được mô tả là Volatile - Dễ bay hơi, bởi vì nếu như nguồn cung cấp điện của máy tính bị chấm dứt [terminated], khi đó tất cả thông tin bên trong loại Memory này sẽ hoàn toàn bị mất.

RAM là loại vi mạch tích hợp được tạo nên từ hàng triệu Bóng bán dẫn - Transistors và Tụ điện - Capacitors. Capacitors là nơi thực sự lưu trữ điện tích, đại diện bằng 0 hoặc 1 đến hệ thống. Transistor giống như một công tắc - Switch.

Đối với Capacitors lưu trữ giá trị nhị phân = 1, sẽ có một số Electrons được lưu trữ bên trong nó mang điện tích âm [negative charge]. Trong khi đó đối với Capacitors có giá trị nhị phân = 0, bên trong nó sẽ Empty - Trống Rỗng.

Khi HĐH tiến hành ghi 1 Bit với 0 Bit, thực sự nó chỉ đang làm trống [emptying] các Electrons đến từ Capacitors cụ thể.

Có một vấn đề đó là những Capacitors này thường không thể giữ điện tích của chúng trong một thời gian dài. Do đó, Memory Controller sẽ chịu trách nhiệm "Recharge - Nạp lại" các giá trị bên trong Capacitors, có nghĩa nó liên tục Reads & Writes các giá trị tương tự đến cho Capacitors.

Nếu Memory Controller không "Refresh" giá trị 1, Capacitor sẽ bắt đầu bị mất các Electrons của nó và trở thành giá trị 0 hoặc giá trị hỏng [corrupted value]. Điều này giải thích cách hoạt động của Dynamic RAM [DRAM].

Data được lưu trữ bên trong RAM Memory Cells - Các ô nhớ, bắt buộc phải liên tục [continually] và tự động [dynamically] được Refreshed, để cho các Bits của chúng không bị biến mất một cách thần thần bí bí. Hành động liên tục Refreshing sẽ mất rất nhiều thời gian, điều đó lý giải tại sao DRAM lại chậm hơn so với Static Ram.

Chú ý : Khi chúng ta đang xử lý các hoạt động của Memory, chúng ta sẽ sử dụng đơn vị đo thời gian Nanoseconds [ns], có nghĩa là một phần tỷ của một giây - Billionth of a Second. Cho nên nếu như chúng ta nhìn vào RAM chip của mình thấy nó ghi 70ns, thì điều đó có nghĩa nó sẽ tiêu tốn 70 nanosecond để Read và Refresh lại mỗi Memory Cell.

Static RAM - SRAM không yêu cầu hành động liên tục Refreshing, nó sử dụng công nghệ khác. Bằng cách lưu giữ các Bits bên trong Memory Cells, mà không cần sử dụng đến Capacitors, nhưng nó lại đòi hỏi nhiều Transistors hơn DRAM.

Vì SRAM không cần phải Refreshed nên nó nhanh hơn so với DRAM, nhưng bởi vì SRAM yêu cầu nhiều Transistors hơn nên nó chiếm nhiều không gian [space] trên RAM chip hơn. Các nhà sản xuất không thể lắp [fit] quá nhiều SRAM Memory cells lên Memory chip như DRAM, đó là lý do tại sao SRAM lại tốn kém, đắt tiền hơn so với DRAM.

Cho nên DRAM rẻ hơn và chậm hơn, còn SRAM lại đắt tiền hơn và nhanh hơn. SRAM thường được sử dụng để Cache, còn DRAM thường được sử dụng trong các RAM Chips.

Chúng ta có rất nhiều loại RAM, lý do chính cho sự tiến hóa không ngừng của các loại RAM này là bởi vì nó ảnh hưởng trực tiếp đến tốc độ của máy tính. Rất nhiều người đã có sự nhầm lẫn, họ nghĩ rằng chỉ cần có CPU nhanh là máy tính của họ sẽ nhanh. Tuy nhiên, loại Memory, Size và Bus Sizes cũng là những thành phần quan trọng ảnh hưởng đến tốc độ của máy tính.

Khi máy tính tiêu tốn nhiều thời gian, di chuyển Data từ một phần nhỏ của Memory sang một phần khác, so với việc thực sự xử lý Data; thì đây gọi là Thrashing - Sự đánh đập [trận đòn]. Điều này làm cho tốc độ của máy tính trở thành rùa bọ, mức độ thất vọng của chúng ta sẽ tăng cao.

Size - Kích thước của Data Bus cũng là một phần quan trọng đối với tốc độ của hệ thống. Bạn có thể tưởng tượng Data Bus giống như một con đường cao tốc, dùng để kết nối các thành phần khác nhau của máy tính. Nếu có 1 tấn dữ liệu bắt buộc phải đi từ Memory đến CPU và chỉ có thể đi trên con đường cao tốc 4 làn xe so với con đường 64 làn xe, thì sẽ có sự Delays - Chậm trễ xảy ra trong việc xử lý.

Cho nên mới nói Processor, Memory type, Memory amount [số lượng] và Bus Speeds là những thành phần vô cùng quan trọng đối với System Performance.

Hardware Segmentation - Phân đoạn Phần Cứng

Các hệ thống có Higher Trust Level có thể cần phải triển khai Hardware Segmentation cho Memory, được sử dụng bởi các Processes khác nhau. Điều này có nghĩa Memory sẽ được seperated - tách biệt Physically thay vì chỉ Logically. Điều này giúp bổ sung thêm một lớp bảo vệ, nhằm đảm bảo Lower-Privileged Process không thể nào truy cập và sửa đổi Memory Space của Higher Level Process.

Sau đây là một số loại RAM mà bạn cần phải "làm quen" với nó :

• Synchronous DRAM [SDRAM] : Synchronizes - Đồng bộ chính bản thân nó với CPU của hệ thống và Đồng bộ tín hiệu [Signal] Input/Output trên RAM chip. SDRAM sẽ điều phối các hoạt động của nó với CPU lock, do đó thời gian của CPU và thời gian của Memory Activities được đồng bộ hóa. Điều này làm tăng tốc độ truyền tải và thực thi Data.

• Extended data out DRAM [EDO DRAM] : Nó nhanh hơn so với DRAM, bởi vì DRAM chỉ có thể truy cập 1 Block duy nhất tại một thời điểm, trong khi đó EDO DRAM lại có thể "capture" Next Block của Data khi First Block đã được gửi đến cho CPU xử lý. EDO DRAM là loại có tính năng"nhìn về phía trước" giúp tăng tốc độ truy cập Memory.

• Burst EDO DRAM [BEDO DRAM] : BEDO DRAM cũng giống như EDO DRAM, nhưng nó có thể truyền tải nhiều Data đến CPU cùng một lúc [Burst]. Nó có thể Reads & Sends đến 4 Memory Addresses trong một khoảng thời gian rất nhỏ.

• Double data rate SDRAM [DDR SDRAM] : Thực hiện các hoạt động Read dựa trên xung nhịp lên và xuống. Cho nên thay vì chỉ thực hiện một hoạt động [operation] trên mỗi xung nhịp, thì DDR SDRAM có thể thực hiện 2 Operations trên mỗi xung nhịp, do đó nó có thể cung cấp gấp đôi Throughput của SDRAM. Về cơ bản, nó làm tăng gấp đôi [double] tốc độ của Memory Activities khi so sánh với SDRAM.

Chú ý : Những loại RAM này đòi hỏi các loại Controller Chips khác nhau để giao tiếp với chúng; Do đó, Motherboards mà các loại Memory này sử dụng thường rất đặc thù trong tự nhiên.

OK, đến đây là đủ về RAM rồi. Bây giờ chúng ta sẽ tiến hành tìm hiểu các loại Memory khác, được sử dụng hầu hết trong mọi máy tính trên thế giới.

Read-only Memory [ROM]

ROM là loại memory Nonvolatile - Không bay hơi, nghĩa là khi máy tính bị tắt đi, Data vẫn được lưu trữ bên trong các Memory Chips. Khi Data được đưa vào bên trong ROM Memory chip, Data sẽ không thể nào thay đổi được nữa. ROM Chips được sản xuất với các Program được thiết kế nằm bên trong nó, chúng được gọi là Firmware.

Programmable read-only memory - PROM là loại ROM có thể sửa đổi - modified, sau khi nó đã được sản xuất. PROM có thể được lập trình chỉ một lần duy nhất, bởi vì Voltage được sử dụng để Write các Bits vào bên trong Memory cells, thực tế sẽ đốt cháy các cầu chì - fuses mà dùng để kết nối các Memory cells.

Các Instructions được "Burned into - đốt cháy vào trong" PROM, bằng cách sử dụng thiết bị lập trình chuyên dụng cho PROM.

Erasable and programmable read-only memory - EPROM là loại ROM có thể Erased - Xóa, Modified - Sửa đổi và Upgraded - Nâng cấp. EPROM lưu trữ Data có thể được xóa bằng Electrically - Điện hoặc Written - Ghi lên nó.

Để xóa Data trên Memory chip, bạn cần phải có thiết bị Handy-Dandy Ultraviolet [UV] Light, dùng để cung cấp mức độ năng lượng cần thiết. EPROM Chip có Quartz Window - Cửa sổ Thạch Anh, đó là nơi để bạn trỏ tia cực tím UV vào nó.

Để xóa một EPROM chip, chúng ta cần phải gỡ bỏ Chip ra khỏi máy tính và thực hiện động tác "vẫy cây đũa phép ma thuật" UV, tất cả Data trên con Chip đó sẽ bị xóa hoàn toàn, chứ không riêng một vài phần nào cả.

EEPROM cũng tương tự như EPROM, nhưng Data Storage của nó có thể được xóa và sửa đổi bằng cách lập trình các vi mạch và tín hiệu Onboard. Hành động này chỉ có thể xóa 1 byte tại một thời điểm cho nên nó diễn ra khá chậm. Bởi vì chúng ta là một xã hội thiếu kiên nhẫn, cho nên đã có những công nghệ tương tự khác xuất hiện nhưng đạt kết quả nhanh hơn.

Flash Memory là loại Memory vô cùng đặc biệt, được sử dụng trong các máy ảnh kỹ thuật số, BIOS chips, Memory Cards cho Laptops và Video Game Consoles. Nó là loại công nghệ Solid-state, nghĩa là nó không có các thành phần chuyển động, thường được sử dụng như là một ổ đĩa cứng hơn là Memory.

Flash Memory về cơ bản di chuyển xung quanh các mức độ Voltages khác nhau để biểu thị rằng 1 hoặc 0 cần phải được lưu trữ tại một Address cụ thể. Nó hoạt động như công nghệ ROM chứ không phải như công nghệ RAM. Ví dụ : Chúng ta sẽ không bị mất các hình ảnh lưu trữ trên Memory Stick chỉ bởi vì chúng ta tắt máy ảnh. RAM là Volatile & Rom là NonVolatile.

Khi Flash Memory cần được tẩy xóa [erased] và cần được quay trở lại [turned back] trở thái ban đầu của nó, Program khởi tạo Internal Circuits - Mạch nội bộ để apply một trường điện từ - electric field. Chức năng Erasing diễn ra trong các Blocks hoặc trên toàn bộ Chip thay vì xóa từng byte tại một thời điểm.

Flash Memory được sử dụng như một ổ đĩa cứng nhỏ trong hầu hết các giải pháp triển khai. Lợi ích của nó so với các ổ cứng thông thường chính là nó nhỏ hơn, nhanh hơn và nhẹ hơn. Vì thế cho nên hãy sử dụng Flash Memory mọi lúc mọi nơi, thay thế cho các ổ cứng cũ kỹ của chúng ta đi các bạn ơi ... Hy vọng sớm đến ngày đó, vì ngày nay Flash Memory còn tương đối đắt tiền so với các ổ cứng thông thường, cho nên việc chuyển đổi qua nó cũng là một khó khăn.

Cache Memory - Bộ nhớ đệm

Cache Memory là loại Memory được sử dụng cho các hoạt động Reading và Writing tốc độ cao. Khi hệ thống giả định rằng, nó cần truy cập nhiều lần [many times] thông tin cụ thể trong suốt thời gian các hoạt động Processing của nó diễn ra, nó sẽ lưu trữ thông tin vào trong Cache Memory để có thể truy cập một cách dễ dàng và nhanh chóng.

Data trong Cache có thể được truy cập nhanh hơn rất nhiều so với Data lưu trữ trong Real Memory. Do đó, bất kỳ thông tin nào CPU đòi hỏi cần phải truy cập nhanh chóng và thường xuyên, nó thường sẽ được lưu trữ trong Cache Memory, qua đó cải thiện tốc độ tổng thể của hệ thống máy tính.

Cũng tương tự như cách bộ não lưu trữ thông tin mà nó thường xuyên sử dụng. Nếu một trong những công việc chính của anh cu Tí là báo giá khóa học CISSP, đòi hỏi anh ta phải cung cấp giá chính xác cho khách hàng, khi đó cu Tí sẽ lưu trữ thông tin học phí này vào một phần trong bộ não của anh ta, từ đó cu Tí có thể dễ dàng và nhanh chóng "truy cập" đến nó.

Thông tin này được lưu trữ tại một loại Cache Memory. Nếu như cu Tí được yêu cầu nhớ lại tên người giáo viên cấp 1 của anh ta, thông tin này có thể sẽ không được lưu trữ trong Cache Memory, mà nó được lưu trữ trong Long-term Storage của cu Tí. Long-term Storage bên trong bộ não của cu Tí được so sánh như là ổ đĩa cứng của hệ thống.

Nó sẽ mất nhiều thời gian hơn để theo dõi và lấy ra thông tin từ ổ cứng so với lấy thông tin từ Cache Memory.Chú ý : Các Motherboards khác nhau có các loại Cache khác nhau. Level 1 [L1] nhanh hơn so với Level 2[L2], và L2 nhanh hơn so với L3. Một số Processors và Device Controllers có Cache Memory được built-in bên trong chúng. L1 và L2 thường được buit-in vào bên trong chính bản thân các Processors và Controllers.

Memory Mapping - Ánh xạ bộ nhớ Okay, đây là bộ nhớ của bạn, đây là bộ nhớ của tui, đây là bộ nhớ của anh Ba Khía. Không ai sử dụng bộ nhớ của người khác cả !

Bởi vì có nhiều loại Memory đang lưu trữ nhiều loại Data khác nhau, nên hệ thống máy tính KHÔNG muốn để cho các User, Process và Application có thể truy cập vào tất cả các loại Memory này bất cứ lúc nào chúng muốn. Việc truy cập vào Memory cần phải được kiểm soát, để đảm bảo Data không bị Corrupted - Hỏng và thông tin Sensitive - Nhạy cảm sẽ Not Available đối với các Unauthorized Processes. Đây là loại kiểm soát diễn ra thông qua Memory Mapping và Addressing.

CPU là một trong những thành phần đáng tin cậy nhất bên trong hệ thống, có thể truy cập trực tiếp [directly] đến Memory. CPU sử dụng Physical Addresses thay vì Pointers [logical addresses] đến Memory segments. CPU có Physical Wires - Dây kết nối vật lý đến các Memory Chips bên trong máy tính. Physical Wires kết nối đến 2 thành phần, Physical Addresses được sử dụng để đại diện cho Intersection - Giao Điểm giữa Wires và Transistors trên Memory Chip.

Software không sử dụng Physical Addresses; Thay vào đó nó sử dụng Logical Memory Addresses. Việc truy cập Indirectly - Gián tiếp vào Memory cung cấp một lớp Access Control giữa Software và Memory, nâng cao hiệu quả trong việc bảo vệ Memory. Figure 5-8 minh họa cách CPU có thể truy cập Memory Directly sử dụng Physical Addresses, còn Software thì bắt buộc phải Memory Indirectly thông qua Memory Mapper.

Khi máy tính chạy các Softwares, nó không muốn Expose - Để lộ bản thân nó ra khi không cần thiết, vì nó không biết được Software đó được lập trình bởi người tốt hay kẻ xấu.

Các máy tính cho phép Software truy cập gián tiếp vào Memory bằng cách sử dụng Index Tables và Pointers, thay vì cho chúng quyền truy cập trực tiếp đến Memory. Đây là cách mà hệ thống máy tính dùng để bảo vệ chính bản thân nó.

Khi chương trình cố gắng truy cập vào Memory, Access Rights - Quyền hạn truy cập của nó sẽ được Verified, rồi sau đó Instructions & Commands mới được thực thi, nhằm đảm bảo các mã nguồn lập trình Badly sẽ không gây ảnh hưởng đến những Programs khác hoặc đến chính bản thân hệ thống.

Applications và các Processes của chúng chỉ có thể truy cập vào Memory được phân bổ cho chúng, như trong Figure 5-9. Đây là loại Memory Architectures cung cấp sự bảo vệ hiệu quả.

Physical Memory Addresses mà CPU sử dụng được gọi là Absolute Addresses - Địa chỉ tuyệt đối. Indexed Memory Addresses mà Software sử dụng được gọi là Logical Addresses - Địa chỉ luận lý.

Như đã giải thích trước đây, một Application hoàn toàn không biết được nó đang sharing Memory với Applications khác. Khi chương trình cần có một Memory Segment để làm việc với nó, chương trình sẽ báo cho Memory Manager biết nó cần bao nhiêu Memory. Memory Manager sẽ cho phép các Applications sử dụng Own Addressing Scheme của riêng mình. Khi Application tạo ra yêu cầu đến những "Phantom" Logical Addresses này, Memory Manager cần phải Map - Ánh xạ Address này đến Physical Address.

Mapping Process - Quá trình ánh xạ được mô tả trong Figure 5-10. Khi Application cần Instructions và Data của nó được processed bởi CPU, Physical Addresses sẽ được nạp vào bên trong Base Register và Limit Register. Khi Thread chỉ ra Instructions cần phải được processed, nó sẽ được cung cấp Logical Address.

Memory Manager ánh xạ Logical Address đến Physical Address, cho nên CPU sẽ biết được vị trí "tọa lạc" [located] của Instruction. Thread thực sự sẽ sử dụng Relative Address - Địa chỉ cân xứng, bởi vì Application sử dụng Address Space từ 0 đến 5000. Khi Thread chỉ ra rằng nó cần thực thi Instruction tại Memory Address 3400, Memory Manager sẽ mapping Logical Address 0 của Thread đến Physical Address, sau đó tìm ra Physical Address dành cho Logical Address 3400.

Chỉ cần xem qua ví dụ sau đây là các bạn sẽ hiểu ngay thôi :

Nếu tôi biết bạn sử dụng một Number System - Hệ Thống Số khác với mọi người trên thế giới, và bạn nói với tôi bạn cần 14 cái đùi gà nướng, tôi sẽ cần phải biết nên bắt đầu từ đâu trong Number Scheme của bạn để tìm ra được chính xác bạn muốn bao nhiêu cái đùi gà nướng.

Vì vậy nếu bạn cho tôi biết trong "thế giới số" của bạn, con số bắt đầu là con số 5, tôi sẽ "map" số 5 đến con số 0, số bắt đầu trong hệ thống số thường dùng của loài người chúng tui. Vì thế cho nên, khi bạn nói với tôi bạn muốn 14 cái đùi gà nướng [Relative Number - Số tương đối], tôi biết rằng bạn bắt đầu với con số 5, do đó tôi sẽ ánh xạ Logical Address của con số 14 đến Physical Number chính là con số 9.

Vì các Application đang hoạt động trong Own World - Thế giới của riêng nó, cho nên nó có Own Addresses - Địa chỉ của riêng nó, và Memory Manager sẽ ánh xạ những giá trị này đến Physical Address, còn được gọi là Absolute Address - Địa chỉ tuyệt đối.

Memory Leaks - Rò rỉ bộ nhớ

Khi Application đưa ra Request đối với Memory Segment, nó sẽ được allocated [phân bổ] một số lượng Memory cụ thể bởi HĐH. Khi Application hoàn thành công việc của nó với Memory, về lý thuyết nó sẽ "báo" cho HĐH biết để release [giải phóng] Memory, nhằm để Memory có thể available cho các Applications khác. Đó là trong trường hợp mọi thứ đều tốt đẹp...

Nhưng có một số Applications được lập trình hết sức nghèo nàn, không chỉ ra cho hệ thống biết được rằng Memory này đã lâu nó không còn sử dụng đến. Nếu việc này xảy ra trong một thời gian đủ dài, HĐH có thể trở nên "chết đói" Memory, điều đó sẽ dẫn đến sự ảnh hưởng nghiêm trọng đối với Performance của hệ thống.

Khi Memory Leak xuất hiện trong thế giới Hacker, nó đã mở ra cánh cửa mới cho các cuộc tấn công Denial-of-service [DOS]. Ví dụ, khi phát hiện ra Memory Leak trong một Unix Application và một phiên bản cụ thể của Telnet Protocol, các Hackers đã khuếch đại vấn đề này lên. Họ liên tục gửi hàng loạt các Requests đến những hệ thống đang bị mắc Vulnerabilities này. Hệ thống sẽ allocate resources cho các Network Requests này, do đó sẽ xảy ra tình trạng càng ngày càng cạn kiệt Memory. Cuối cùng hệ thống sẽ bị Out of Memory và treo !Chú ý : Memory Leaks có thể là bị gây ra bởi HĐH, Applications và Software Drivers.

Có 2 Countermeasures chính có thể giúp chống lại vấn đề Memory Leaks :

1/ Phát triển Code cho thật tốt, thật chính xác phần Releases Memory.

2/ Sử dụng Garbage Collector. Garbage Collector là Software có thể vận hành Algorithm - Thuật toán để xác định Unused Commited Memory [bộ nhớ bị giam giữ mà các application, process không còn sử dụng đến nữa], sau đó nó sẽ báo cho HĐH đánh dấu rằng Memory đó "available". Các loại Garbage Collector khác nhau, hoạt động với các HĐHs, Programming Languages và Algorithms khác nhau.

Virtual Memory - Bộ nhớ ảo

RAM của tui đang bị "overflowing" ! Tui có thể sử dụng chút ít không gian ổ đĩa cứng của bạn được không ? Phản hồi : NO !, tui không thích bạn.

Secondary Storage được coi là phương tiện lưu trữ Nonvolatile, bao gồm những thứ như : ổ đĩa cứng của máy tính, ổ đĩa mềm, CD-ROMs. Khi RAM và Secondary Storage được Combined - Hợp nhất, kết quả sẽ xuất hiện Virtual Memory.

Hệ thống sẽ sử dụng Hard Drive Space - Không gian của ổ đĩa cứng để Extend - Mở rộng cho RAM Memory Space. Swap Space dự trữ một phần Hard Drive Space để extend khả năng của RAM. Các hệ thống Windows sử dụng Pagefile.sys để reverse - dự trữ vùng không gian này.

Khi hệ thống gặp tình trạng bị Fills Up - Lấp đầy RAM Memory Space, nó sẽ Writes Data từ Memory vào trong Hard Drive. Khi một Program requests truy cập đến phần Data này, nó sẽ được đưa từ Hard Drive trở ngược [back] về Memory trong các Units cụ thể, được gọi là Pages. Quá trình này được gọi là Virtual Memory Paging.

Việc truy cập Data được lưu trữ trong Pages trên Hard Drive, sẽ tốn nhiều thời gian hơn so với việc truy cập Data được lưu trữ trực tiếp trong Memory, bởi vì khi truy cập Data trên Hard Drive bắt buộc phải diễn ra các hoạt động Read/Write trực tiếp lên Physical Disk.

Internal control blocks, được maintained bởi HĐH, theo dõi các Page Frames đang "cư ngụ" trong RAM và những gì available "offline", sẵn sàng để được gọi vào RAM cho mục đích Execution hoặc Processing nếu cần thiết. Phần thưởng cho việc này chính là : Trong có vẻ như hệ thống có thể lưu trữ một số lượng thông tin và Program Instructions đáng kinh ngạc, như trong Figure 5-11.

Có một vấn đề liên quan đến Security trong lúc sử dụng Virtual Swap Space, đó là khi hệ thống bị Shutdown hoặc các Processes đã sử dụng swap space bị Terminated, các Pointers trỏ đến Pages được Reset - Thiết lập lại thành "Available", ngay cả khi Data thực sự vẫn còn tồn tại Physically trên Disk. Những Data này có thể bị compromised và bị captured.

Trên những HĐH sở hữu mức độ bảo mật cao cấp, chúng có thói quen Wipe - Xóa Sạch Swap Spaces sau khi Process thực hiện xong việc với nó, trước khi nó được sử dụng một lần nữa. Ngoài ra chúng còn có thói quen xóa luôn Data này trước khi shutdown hệ thống, tại thời điểm đó HĐH sẽ không còn duy trì bất kỳ Control nào dành cho những việc xảy ra trên bề mặt ổ cứng nữa.

Chú ý : Nếu một Program, File hoặc Data đã được encrypted và được lưu trên ổ đĩa cứng, chúng sẽ được decrypted khi được sử dụng bởi Controlling Program. Trong khi những data Unencrypted đang nằm trong RAM, hệ thống có thể sẽ Write các Data này vào trong Swap Space trên ổ cứng, trong trạng thái Unencrypted.

Những kẻ tấn công đã tìm ra cách để truy cập một cách trái phép vào Space này, khiến cho Data có thể bị xâm phạm và bị đánh cắp.

CPU Modes and Protection Rings - Chế độ CPU và Vòng Tròn Bảo Vệ

Nếu HĐH muốn có được trạng thái Stable, nó cần phải tự bảo vệ được chính bản thân mình với các Users và các Applications của nó. Điều này đòi hỏi khả năng phân biệt giữa các Operations được thực hiện thay mặt cho chính bản thân HĐH và các Operations được thực hiện thay mặt cho Users hoặc Applications.

Vấn đề này có thể khá phức tạp, bởi vì các Software có thể truy cập vào Memory Segment, gửi Instructions đến CPU và truy cập vào Secondary Storage cùng một lúc. Mỗi User Application [email client, antivirus program, web browser, personal firewall, vân vân] cũng có thể cố gắng tương tác Same types - Cùng một loạt các hoạt động giống nhau cùng một lúc. HĐH bắt buộc phải theo dõi tất cả những Events này và đảm bảo không một ai trong số chúng vi phạm Security Policy tổng thể của hệ thống.

HĐH có một số cơ chế bảo vệ để đảm bảo các Processes không gây ra ảnh hưởng tiêu cực cho nhau hoặc cho các thành phần Critical khác của chính bản thân hệ thống. Một trong các cơ chế đó đã được đề cập đến : Memory Protection.

Ngoài ra còn một cơ chế bảo mật khác mà hệ thống sử dụng đó chính là : Protection Rings - Vòng Bảo Vệ.

Các vòng này cung cấp Strict Boundaries - Ranh giới nghiêm ngặt & xác định xem những Processes nào hoạt động bên trong mỗi Ring có thể truy cập và thực hiện những Operations nào. Các Processes hoạt động Inner Ring - Bên trong Vòng, có nhiều Privileges hơn so với các Processes hoạt động Outer Rings - Bên ngoài Vòng, bởi vì Inner Rings chỉ cho phép các thành phần & các Processes đáng tin cậy nhất hoạt động bên trong chúng.

Mặc dù các HĐHs có thể khác nhau về số lượng Protection Rings mà chúng sử dụng, nhưng chúng vẫn có điểm chung : các Processes thực thi bên trong Inner Ring thường được xem là Privileged Mode hoặc Supervisor Mode, còn các Processes hoạt động ở Outer Ring thường được xem là thực thi trong User Mode.

Chú ý : Ring Architecture - Kiến trúc Vòng được sử dụng bởi hệ thống bị chi phối [dictated] bởi Processor - Bộ Vi Xử Lý và HĐH. Hardware Chip [processor] được chế tạo ra để cung cấp một số lượng Rings nhất định, và HĐH được phát triển ra cũng cần phải hoạt động được bên trong Ring Structure này. Đây là một trong những lý do tại sao mà một HĐH có thể hoạt động với chip Intel nhưng lại không hoạt động được với chip Alpha. Vì chúng có Architectures và cách diễn dịch Instruction Sets khác nhau.

Operating System Components - Các thành phần của HĐH thường hoạt động trong Ring mà cho phép chúng truy cập đến hầu hết Memory Locations, Peripheral Devices [thiết bị ngoại vi], System Drivers và các Configuration Parameters nhạy cảm. Bởi Ring này cung cấp khả năng truy cập đến quá nhiều Critical Resources, cho nên nó là Ring được bảo vệ nhiều nhất.

Applications thường hoạt động trong Ring 3, điều đó sẽ giới hạn loại Memory, Peripheral Device và Driver Access Activity mà Applications có thể tương tác, được kiểm soát thông qua OS Services hoặc System Calls. Các Rings khác nhau được minh họa trong Figure 5-12. Loại Commands & Instructions được gửi đến CPU từ Applications ở Outer Rings sẽ có rất nhiều sự hạn chế.

Nếu một Application cố gắng gửi các Instructions đến CPU mà nằm ngoài quyền hạn [permission] của nó, CPU sẽ xử lý sự vi phạm này như một Exception - Trường hợp ngoại lệ và có thể sẽ hiển thị thông báo General Protection Fault - Lỗi bảo vệ chung hoặc Exception Error và CPU sẽ cố gắng shut down Application vi phạm ngay lập tức.

Protection Rings hỗ trợ cho những yêu cầu về Availability, Intergrity và Confidentiality của các HĐH Đa Nhiệm. Architecture được sử dụng phổ biến nhất sẽ cung cấp 4 Protection Rings :

• Ring 0 Operating system kernel • Ring 1 Remaining parts of the operating system • Ring 2 I/O drivers and utilities • Ring 3 Applications and user activity

Những vòng tròn bảo vệ này cung cấp một Intermediate Layer - Lớp Trung Gian giữa các Subjects và các Objects, được sử dụng để kiểm soát truy cập khi một Subjects cố gắng truy cập đến một Object. Vòng tròn sẽ xác định Access Level - Mức độ truy cập đến những tài nguyên hệ thống nhạy cảm.

Con số Vòng càng thấp thì đặc quyền càng nhiều đối với các Process vận hành bên trong vòng. Mỗi Subject và Object được gán một con số logically [từ 0 đến 3] tùy thuộc vào mức độ tin cậy của HĐH gán cho nó.

Subject trong Ring 3 sẽ không thể nào truy cập trực tiếp [directly] đến Object trong Ring 1, nhưng Subject trong Ring 1 lại có thể truy cập trực tiếp đến Object trong Ring 3. Các chủ thể chỉ có thể truy cập đến Objects bên trong chính Ring của nó, không thể tương tác trực tiếp đến các Objects nằm ở những Rings có đặc quyền cao hơn.

Khi một Application cần truy cập đến các thành phần trong Rings mà nó không được phép truy cập trực tiếp, nó sẽ request HĐH thực hiện những công việc cần thiết này. Điều này được xử lý thông qua System Calls, nơi mà HĐH sẽ thực thi các Instructions không được cho phép trong chế độ User Mode.

Request được gửi đến OS Service, nó hoạt động ở Higher Privilege Level - Cấp độ đặc quyền cao hơn và có thể thực hiện những công việc nhạy cảm hơn.

Khi HĐH thực thi các Instructions cho các Processes trong Ring 0 và Ring 1, nó sẽ hoạt động ở chế độ Supervisor Mode hoặc Privileged Mode. Khi HĐH thực thi các Instructions cho các Applications và Processes trong Ring 3, nó sẽ hoạt động ở chế độ User Mode. User Mode cung cấp một môi trường có nhiều hạn chế cho Application hoạt động bên trong nó, điều đó giúp bảo vệ hệ thống tránh khỏi những phần mềm "nguy hiểm".

Nếu CPU Execution Modes và Protection Rings còn khá mới mẻ đối với bạn, thì hãy suy nghĩ Protection Rings như những chiếc thùng - buckets. HĐH hoạt động bên trong Structure - Cấu trúc và Confines - Sự giới hạn được cung cấp bởi CPU. CPU cung cấp cho HĐH những cái thùng khác nhau, được dán nhãn từ 0 đến 3.

HĐH bắt buộc phải sắp xếp các Processes một cách hợp lý vào những cái thùng khác nhau này, dựa trên Trust Level - Mức độ tin cậy của HĐH đối với các Processes. Operating System Kernel - Nhân HĐH là thành phần đáng tin cậy nhất, nó và các Processes của nó sẽ được đặt vào thùng số 0. Các Processes HĐH còn lại sẽ được đặt vào thùng số 1 và tất cả các User Applications sẽ được đặt vào thùng số 3. CPU sẽ cho biết có bao nhiêu cái thùng còn HĐH sẽ được phát triển để sử dụng số thùng này !Chú ý : Nhiều HĐH ngày nay đã không còn sử dụng Ring 2 nữa.

Operating System Architecture - Kiến trúc Hệ Điều Hành

Hệ Điều Hành có thể được phát triển bằng cách sử dụng một số loại hình Architecture. Architecture là framework chỉ ra cho thấy các Services & Functions của HĐH được đặt vào [placed] như thế nào và cách để tương tác với chúng. Phần này sẽ giới thiệu đến các bạn độc giả một số loại hình Architectures như sau : Monolithic, Layered, Client/Server.

Monolithic OS Architecture - Kiến trúc HĐH Khối thường được gọi là "The Big Mess - Đống hỗn độn to tướng" bởi vì những sự thiếu sót trong cấu trúc của nó. HĐH chủ yếu được tạo nên từ nhiều Procedures khác nhau, mà có thể "call" đến nhau theo một cách thức lộn xộn - haphazard manner. Trong những loại hệ thống này, Modules of Code có thể gọi đến nhau khi cần thiết.

Communication giữa các Modules khác nhau không theo một cấu trúc nào cả, không được kiểm soát [controlled] như trong Layered Architecture và Data Hiding không được cung cấp. MS-DOS là một ví dụ về HĐH mang kiến trúc Monolithic.

Layered OS Architecture - Kiến trúc HĐH Phân Lớp, tách biệt System Functionality - Chức Năng Hệ Thống thành Hierarchical Layers - Nhiều Lớp Phân Cấp. Ví dụ về một hệ thống được phát triển theo Layered Architecture, khá kỳ lạ, được gọi là THE [Technische Hogeschool Eindhoven] Multiprogramming System. THE có 5 Layers chức năng :

Layer 0 chịu trách nhiệm truy cập vào Processor và cung cấp Multiprogramming Functionality.. Layer 1 chịu trách nhiệm Memory Management. Layer 2 chịu trách nhiệm Interprocess Communication - Giao tiếp liên tiến trình. Layer 3 chịu trách nhiệm xử lý I/O Devices. Layer 4 là nơi mà các Applications cư ngụ. Layer 5 là User Layer, không được triển khai trực tiếp bởi THE.

Mỗi Processes ở các Layers khác nhau, đều có Interfaces được sử dụng cho các Processes trong các Layers trên và dưới chúng. Điều này khác biệt so với kiến trúc Monolithic, trong đó các Modules khác nhau có thể giao tiếp với bất kỳ mọi Moduel khác.

Layered OS Architecture cung cấp khả năng Data Hiding - Ẩn Dữ Liệu, có nghĩa là Instructions và Data tại các Layers khác nhau không có quyền truy cập trực tiếp đến Instructions và Data ở bất kỳ Layers nào khác. Mỗi Procedures tại mỗi Layer chỉ có thể truy cập vào Data và Instruction sets của riêng nó, mà nó cần để thực hiện chính các công việc của nó.

Nếu Procedure có thể truy cập đến quá nhiều Procedures hơn mức cần thiết, điều này có thể mở ra cánh cửa thành công cho nhiều sự thỏa hiệp - compromises. Ví dụ, nếu kẻ tấn công có thể thỏa hiệp và giành quyền kiểm soát một trong các Procedure, và Procedure này có thể truy cập trực tiếp đến tất cả các Procedures khác, kẻ tấn công có thể nhắm đến việc thỏa hiệp Privileged Procedure và có thể thực hiện nhiều hoạt động tàn phá dữ dội hơn nữa.

Monolithic OS chỉ cung cấp một Layer cho Security. Trong hệ thống Layered, mỗi Layer sở hữu Security và Access Control của riêng nó. Nếu chỉ có 1 Layer chứa tất cả các cơ chế bảo mật để ra quyết định Security cho tất cả các Layers khác, khi đó 1 Layer sẽ biết quá nhiều Objects ở các Layers khác, điều này vi phạm trực tiếp đến khái niệm Data Hiding.

Modularizing Software và Code của nó làm gia tăng Assurance Level - Mức độ đảm bảo của hệ thống, bởi vì nếu như có 1 Module bị thỏa hiệp, nó không có nghĩa là các Modules khác cũng bị Vulnerable. Ví dụ về một số HĐH sử dụng kiến trúc Layered : THE, VAX/VMS, Multics và Unix [mặc dù THE và Multics từ lâu đã không còn được sử dụng].

Chú ý : Đừng nhầm lẫn Client/Sever OS Architecture với Client/Server Network Architecture nhé các bạn. Trong ngữ cảnh Network, Application hoạt động trong mô hình Client/Server bởi vì nó cung cấp khả năng tính toán phân tán - Distributed Computing. Phần Client chính là các Application cư ngụ trên các máy Workstations và Phần Server thường là một Back-end Database hoặc Server.

Một phương pháp khác để thiết kế hệ thống chính là sử dụng kiến trúc Client/Server, nghĩa là các phần Software và Functionality mà trước đây nằm trong Monolithic Kernel thì bây giờ sẽ nằm ở những cấp độ cao hơn của HĐH. OS Functions được chia thành những Processes khác nhau, hoạt động trong User Mode thay vì Kernel Mode.

Mục đích của kiến trúc Client/Server chính là để di chuyển càng nhiều Code ra khỏi Kernel Mode càng tốt, để hệ thống có một Kernel tinh gọn hơn, được gọi là Microkernel. Trong mô hình này, Requesting Process được gọi là Client, còn Process đáp ứng Request được gọi là Server.

Server Process có thể là File System Server, Memory Server, I/O Server hoặc Process Server. Những Servers này thường được gọi là Subsystems. Client có thể là một User Process hoặc OS Process.

Domains

Domain được định nghĩa là một tập hợp các Objects mà một Subject có thể truy cập đến. Domain này có thể là tất cả các Resources mà một người dùng có thể truy cập, tất cả các files available cho một program, memory segments available cho một process, hoặc có thể là các services và processes available cho một Application.

Subject cần phải được truy cập và sử dụng Objects [resources] để hoàn thành các nhiệm vụ của nó, Domain sẽ xác định xem Objects nào có thể cung cấp được cho Subject và Objects nào là "bất khả xâm phạm - untouchtable", mà Subject không được phép sử dụng đến.Chú ý : Hãy nhớ rằng Thread là một phần của Process. Khi Thread được tạo ra, nó chia sẻ cùng một Domain [resources] như Process của nó.

Những Domains này được xác định [identified], được tách biệt [separated] và được thi hành chặt chẽ. HĐH và CPU hoạt động ở một trong hai chế độ Privileged Mode hoặc User Mode. Lý do phải sử dụng những Modes khác nhau này chính là để xác định các Domains khác nhau, được quyết định bởi Protection Ring.

Khi Instructions của một Process được thực thi trong chế độ Privileged Mode, Process này có Domain lớn hơn để hoạt động [hoặc có nhiều Resources để truy cập]; Do đó, nó có thể thực hiện nhiều hoạt động hơn. Khi OS Process hoạt động trong chế độ Privileged Mode, nó có thể truy cập vào nhiều Memory Segments hơn, có thể transfer Data từ UnProtected Domain sang Protected Domain, và còn có thể truy cập & tương tác trực tiếp với các Hardware Devices.

Application hoạt động trong chế độ User Mode không thể nào truy cập trực tiếp đến Memory, chỉ có một số lượng Resources hạn chế dành cho nó. Chỉ có một Memory Segment nhất định dành cho nó và Segment này bắt buộc phải được truy cập một cách gián tiếp, có sự kiểm soát rõ ràng [controlled].

Process cư trú trong Privileged Domain cần có khả năng thực hiện các Instructions và xử lý Data của nó, với sự đảm bảo rằng các Programs trong những Domain khác sẽ không gây bất kỳ ảnh hưởng tiêu cực nào đến môi trường của nó. Điều này được gọi là Execution Domain.

Bởi vì các Processes trong Privileged Domain có thể truy cập đến những Resources nhạy cảm, cho nên môi trường của nó bắt buộc phải được bảo vệ nghiêm ngặt khỏi Rogue Program Code hoặc những hoạt động Unexpected từ những Programs trong các Domains khác. Một số hệ thống có thể chỉ có Distinct User và Privilege Areas, trong khi những hệ thống khác có thể sở hữu kiến trúc phức tạp chứa đến 10 Execution Domains.

Execution Domain có một sự tương quan trực tiếp đến Protection Ring. Vòng tròn bảo vệ có con số càng nhỏ thì càng có nhiều đặc quyền và Domain càng lớn. Khái niệm này được mô tả trong Figure 5-13.

Layering and Data Hiding - Phân Lớp và Ẩn Dữ Liệu

Thuật ngữ Layering và Data Hiding thường được sử dụng khi nói đến các cơ chế bảo vệ HĐH, ngay cả trong kiến trúc Client/Server, bởi vì nó cũng sử dụng Layering và Data Hiding để bảo vệ chính bản thân nó.

Layered OS Architecture chủ yếu giải quyết cách bố trí chức năng HĐH. Nó cung cấp tính năng của nó trong một hệ thống phân cấp, trong khi đó Client/Server OS Architecture cung cấp chức năng nghiêng về cách Linear - Tuyến tính nhiều hơn. Một Request sẽ không phải đi qua nhiều Layers khác nhau trong kiến trúc Client/Server. Request chỉ đi qua Subsystem cần thiết.

Tuy nhiên về mặt an ninh, cả hai kiến trúc này đều sử dụng Layer và Data Hiding để bảo vệ các Processes được xem là Critical đối với HĐH.

Thật sự có quá nhiều Terms - Thuật ngữ mà chúng ta phải nhớ : Execution domains, Protection Rings, Layering, Data Hiding, Protection Domains, CPU Modes, vân vân. Bởi vì trong thực tế tất cả chúng chính là những cách khác nhau để mô tả cùng một điều tương tự diễn ra trong tất cả các HĐH ngày nay.

Đối với những người lần đầu tiên tiếp cận với những chủ đề này, họ sẽ cảm thấy có quá nhiều khái niệm trong có vẻ Discrete - Rời rạc và hoàn toàn không liên quan gì đến bảo mật cả. Nhưng trong thực tế, những khái niệm này đã "làm việc với nhau" từ rất lâu, theo một cách thức sắp đặt rất hiệu quả cho mục đích bảo vệ toàn bộ HĐH.

Như đã thảo luận trước đây, HĐH và CPU hoạt động trong cùng một Architecture, điều đó cung cấp Protection Rings. Protection Domain của một Process [execution domain] được xác định bởi Protection Ring mà nó cư trú bên trong đó. Khi Process cần CPU thực thi các Instructions của nó, CPU sẽ hoạt động trong một Mode cụ thể, có thể là User Mode hoặc Privileged Mode, phụ thuộc vào Protection Ring của Process đó.

Layering và Data Hiding được cung cấp bằng cách Placing - Đặt các Processes khác nhau vào trong những Protection Rings khác nhau và kiểm soát việc giao tiếp giữa Less Trusted Processes với More Trusted Processes. Cho nên, Layering chính là "con đường" để cung cấp Buffers - Vùng đệm giữa các Processes đáng tin cậy [Trusted] và các Processes ít được tin cậy hơn [less trusted].

Less Trusted Processes không thể giao tiếp trực tiếp với More Trusted Processes, mà thay vào đó nó bắt buộc phải gửi các Requests của nó đến OS Service. Service này hoạt động như một nhà môi giới hoặc một kẻ trung gian, nhằm đảm bảo không xảy ra việc truy cập trái phép đến More Trusted Processes. Kiến trúc này bảo vệ tổng thể cho HĐH, bao gồm tất cả Applications và các hoạt động của Users đang diễn ra bên trong nó.

The Evolution of Terminology - Sự tiến hóa của Thuật Ngữ

Mặc dù về mặt lý thuyết, Monolithic, Layered và Client/Server Architectures là diễn tả cách HĐH được xây dựng. Tuy nhiên chuyên sâu hơn, những thuật ngữ này chủ yếu tập trung vào vấn đề Kernel được xây dựng như thế nào.

Trước đây có rất nhiều thuật ngữ tương đồng, gây bối rối cho những người tìm hiểu về chúng, ví dụ như OS Framework còn gọi là Monolithic Framework, rồi có một thuật ngữ chỉ áp dụng cho kernel gọi là Monolithic Kernel ... Nhưng ngày nay, tất cả những thuật ngữ này đã được gộp chung lại làm một trong kỳ thi CISSP, bất cứ khi nào bạn thấy thuật ngữ "Monolithic System" thì có thể hiểu nó đề cập đến vấn đề Kernel được xây dựng như thế nào. Chú ý : Hãy nhớ rằng Kernel Mode, Privileged Mode và Supervisory Mode đều được hiểu chung một nghĩa.

Monolithic Kernel ý nói tất cả các hoạt động của Kernel đều làm việc trong chế độ Privileged Mode, như minh họa trong Figure 5-14.

Điều này có nghĩa các chức năng của HĐH [process, file, memory, I/O management ...] sẽ hoạt động trong Ring 0 như chúng ta đã thảo luận trước đây. Windows NT, 2000 và Vista đều được coi là Monolithic Systems bởi vì tất cả các OS Services của chúng đều được thực thi trong chế độ Kernel Mode. Mặt khác, điều này cũng gây ra một Security Risk - Rủi Ro Bảo Mật, bởi vì nếu như có 1 Process bên trong Kernel bị "fail", nó có thể làm ảnh hưởng đến toàn bộ Kernel.

Nó cũng có nghĩa càng nhiều Code vận hành trong chế độ Privileged Mode, thì càng nhiều Code sẽ có nguy cơ trở thành nạn nhân bị khai thác bởi kẻ tấn công, đem lại cho kẻ tấn công khả năng kiểm soát High Level của hệ thống. Điều này có nghĩa việc tạo ra Monolithic System an toàn là vô cùng phức tạp và rất khó để đảm bảo mặt Security.

Lý do mà HĐH Windows và HĐH Linuxs đều được phát triển để sử dụng Kernel chính là bởi vì Performance. Khi một số thành phần của Kernel hoạt động trong chế độ User Mode thay vì Kernel Mode, thì sẽ phải mất nhiều thời gian hơn để CPU thực hiện các Instructions của chúng, bởi vì sự thay đổi chế độ từ User Mode sang Kernel Mode và lại quay trở lại một lần nữa.

Điều này có nghĩa là hầu hết các HĐH ngày nay đều chủ yếu sử dụng Ring 0 và Ring 3 của Protection Ring Architecture, đã được mô tả trong phần trước. Kể từ khi các Drivers hoạt động trong chế độ Privileged Mode, thì điều quan trọng chính là các Drivers phải được viết đúng và không độc hại trong bất kỳ hình thức nào.

Nhiều Device Drivers được cung cấp bởi các bên thứ ba, thật khó để biết được chúng có được phát triển đúng cách và an toàn hay không. Đây là lý do tại sao Microsoft tạo ra các yêu cầu vô cùng chặt chẽ đối với các Drivers trong HĐH Vista của họ. Các nhà cung cấp Driver Third-party bắt buộc phải đáp ứng được các tiêu chuẩn khắt khe của Microsoft, trước khi HĐH cho phép nạp Drivers vào trong hệ thống.

Virtual Machines - Máy Ảo

Nếu bạn là một tín đồ máy tính trong mấy chục năm qua, hẳn bạn còn nhớ đến những trò chơi không phức tạp, không nhiều hình ảnh như những trò chơi ngày nay. Pong & Asteroids là những gì mà chúng ta đã chơi hồi còn trẻ. Trong những ngày đầu tiên chập chững, các trò chơi này chỉ có 16-bit và được viết để hoạt động trong môi trường 16-bit MS-DOS.

Khi HĐH Windows của chúng ta chuyển đổi từ 16-bit sang 32-bit, HĐH 32-bit có khả năng Backward Compatible - Tương thích ngược, cho nên một số người vẫn có thể tải và chơi các trò chơi 16-bit trong một môi trường mà trò chơi đó không thể nào "hiểu" được. Bởi vì HĐH đã tạo ra Virtual Machines - Máy ảo để những trò chơi này vận hành bên trong nó.

Khi 16-bit Application cần tương tác với HĐH, nó sẽ tạo ra các System Calls và tương tác với Memory của máy tính, theo cách này nó sẽ chỉ hoạt động với 16-bit OS mà thôi, 32-bit OS sẽ không chơi được theo cách này. Cho nên, Virtual Machine trong HĐH 32-bit sẽ Simulates - Mô phỏng một HĐH 16-bit và khi 16-bit Application make request, HĐH sẽ Converts - Chuyển đổi 16-Bit Request thành 32-bit Request [điều này được gọi là Thunking] và phản hồi lại cho các Requests hợp lệ. Khi HĐH gửi phản hồi lại cho Request này, nó sẽ thay đổi 32-bit Reply thành 16-bit Reply để 16-bit Application có thể hiểu được nó.

Ngày nay, Virtual Machines càng tiên tiến hơn. Ảo hóa về cơ bản cho phép một thiết bị Single Hardware có thể vận hành nhiều HĐH đồng bộ hóa, tăng cường sức mạnh xử lý, tận dụng tối đa khả năng của máy tính và còn rất nhiều lợi ích khác nữa. Việc tạo ra các thực thể [instances] ảo hóa của HĐH, Applications và Storage Devices được gọi là Virtualization - Ảo hóa.

Theo Thuật ngữ chuyên môn ngày nay, Virtual Instance của một HĐH được biết đến như một Virtual Machine. Virtual Machine thường được gọi là Guest, được thực thi trong Host Environment. Virtualization - Ảo hóa cho phép một môi trường Single Host có thể thực thi Multiple Guests cùng một lúc, các Virtual Machines này có thể tự động hóa phân chia Resources từ một hệ thống Physical thông thường.

Computer Resources chẳng hạn như RAM, Processors và Storage được mô phỏng thông qua Host Environment. Virtual Machines không trực tiếp truy cập vào những tài nguyên này; Thay vào đó, chúng giao tiếp với Host Environment chịu trách nhiệm quản lý System Resources. Điều này có nghĩa là bạn chỉ cần 1 máy tính duy nhất mà có thể chạy nhiều HĐH khác nhau cùng một lúc. Ví dụ, bạn có thể chạy Windows 7, Ubuntu Linux, Windows 2008 cùng một lúc trên một máy tính duy nhất.

Hãy thử suy nghĩ về một ngôi nhà có nhiều căn phòng khác nhau, mỗi HĐH sẽ có một căn phòng của riêng nó, mỗi căn phòng sẽ cùng chia sẻ một nguồn Resources mà căn nhà cung cấp : điện, nước, mái nhà, vân vân. HĐH "sống" trong một căn phòng riêng biệt, mà KHÔNG cần biết hoặc KHÔNG cần tương tác với các HĐHs trong những căn phòng khác, để tận dụng nguồn tài nguyên được cung cấp bởi tòa nhà.

Khái niệm trên cũng xảy ra tương tự trong bối cảnh máy tính : Mỗi HĐH được chia sẻ một lượng Resources cụ thể, được cung cấp bởi hệ thống Physical, chẳng hạn như Memory, Buses, CPU, vân vân. Chúng "sống" và hoạt động trong chính những "căn phòng" riêng của chúng, đó là Guest Virtual Machines. Physical Computer bản thân nó chính là Host - Chủ Nhà.

Tại sao lại ảo hóa ? Một trong những lý do thực tế nhất, đó chính là vì nó rẻ hơn so với việc trang bị một hệ thống Physical đầy đủ cho mỗi HĐH. Nếu chúng có thể cùng nhau vận hành trên 1 hệ thống duy nhất và chia sẻ cùng một nguồn Physical Resources cho nhau, chi phí của chúng ta sẽ được giảm thiểu đáng kể. Điều này cũng giống như việc chúng ta Share tiền nhà vậy đó. Thuê nguyên 1 căn, ngăn phòng ra rồi chia tiền thuê nhà với những người khác, tất cả có thể cùng chia sẻ nhà và nguồn tài nguyên bên trong nhà.

Sau đây là một danh sách khá hữu ích : www.kernelthread.czm/publications/virtualization đề cập đến những lý do tại sao phải sử dụng ảo hóa, ảo hóa trong những môi trường khác nhau. Nó đã được viết cách đây khá nhiều năm, nhưng vẫn còn được áp dụng cho đến ngày nay và trong kỳ thi CISSP :

• Virtual Machines có thể được sử dụng để Consolidate - Hợp nhất workloads - khối lượng công việc từ những Servers ít sử dụng [underutilized] sang ít Server hơn, có thể từ 4 Servers ít dùng đến hợp nhất thành 1 Servers duy nhất. Lợi ích của việc này là tiết kiệm Hardware, chi phí môi trường, chi phí quản lý và điều hành cơ sở hạ tầng Server.

• Có nhu cầu chạy các Legacy Applications - Ứng dụng "cổ" bằng Virtual Machines. Legacy Application có thể không chạy trên các Hardware hoặc các HĐH mới, nên cần build riêng một con máy ảo Windows 95 để chạy Legacy Application abcd nào đó. Thậm chí nếu như có một số Server ít sử dụng đến, ta có thể hợp nhất luôn cả một số Applications chạy trên đó.

• Virtual Machines có thể được sử dụng để cung cấp Secure, Isolated Sandboxes - Cô lập Sandboxes để chạy các ứng dụng không đáng tin cậy. Thậm chí chúng ta còn có thể tạo ra một môi trường thực thi tự động, chẳng hạn bạn tải một cái gì đó từ Internet về và đem vào Virtual Machines để chạy nó. Virtualization - Ảo hóa là một khái niệm vô cùng quan trọng trong việc xây dựng Secure Computing Platforms - Nền Tảng Máy Tính An Toàn.

• Virtual Machines có thể được sử dụng để tạo ra HĐH hoặc Execution Environments - Môi trường thực thi với Resource Limits - Giới hạn tài nguyên, Resource Guarantees - Đảm bảo tài nguyên. Việc phân chia tài nguyên thường sẽ hand-in-hand với Quality of Service trong việc tạo ra HĐH cho phép QoS.

• Virtual Machines có thể cung cấp Illusion - "ảo ảnh" của Hardware hoặc Hardware Configuration mà bạn không có [chẳng hạn như SCSI Devices hoặc Multiple Processors]. Virtualization cũng có thể được sử dụng để giả lập mạng lưới với nhiều máy tính độc lập.

• Virtual Machines có thể được sử dụng để chạy nhiều HĐHs cùng một lúc: các Versions khác nhau hoặc thậm chí là các hệ thống hoàn toàn khác nhau.

• Virtual Machines cho phép khả năng Debugging mạnh mẽ và theo dõi giám sát Performance. HĐH có thể được Debugged mà không bị mất hiệu suất hoặc có thể giả lập lên các kịch bản Debugging phức tạp hơn.

• Virtual Machines có thể Isolate - Cô lập những gì mà chúng vận hành, do đó chúng có thể cung cấp Fault và Error Containment - Ngăn chặn lỗi. Chúng ta có thể chủ động Inject Faults - Chèn Lỗi vào bên trong Software để nghiên cứu hành vi tiếp theo của nó.

• Virtual Machines là những công cụ tuyệt vời để nghiên cứu và thí nghiệm. Chúng có thể Encapsulate - Đóng gói toàn bộ trạng thái của một hệ thống đang vận hành : chúng ta có thể save State, kiểm tra nó, chỉnh sửa nó, nạp lại nó [reload], vân vân.

• Virtualization có thể thực hiện các nhiệm vụ như System Migration, Backup và Recovery dễ dàng và tiện dụng hơn.

• Virtualization là mặt hàng khá phổ biến trong các nhà cung cấp dịch vụ đặt Hosting. Có rất nhiều lợi ích từ việc ảo hóa chẳng hạn như lưu trữ an toàn, chi phí hiệu quả và nhiều điều hấp dẫn khác nữa.

Additional Storage Devices - Thiết bị lưu trữ bổ sung

Bên cạnh Memory Environment thì còn rất nhiều loại Physical Storage Devices cần phải được đề cập đến, cùng với các vấn đề bảo mật mà có thể gây ảnh hưởng trực tiếp đến chúng. Rất nhiều, nếu không muốn nói là tất cả các thiết bị lưu trữ được sử dụng ngày nay đều có khả năng cho phép đánh cắp Data hoặc bị thỏa hiệp Data bên trong tổ chức.

Floppy Disks - Ổ đĩa mềm, dung lượng lưu trữ rất nhỏ chỉ khoảng 1.44MB, từ lâu đã được biết đến như là một nguồn gốc của Viruses và Data Theft - Đánh cắp dữ liệu. Một tên trộm có quyền truy cập vật lý đến máy tính với một HĐH không an toàn, có thể sử dụng một Floppy Disk cơ bản để Boot hệ thống.

Nhiều máy tính có BIOS cho phép máy khởi động [booted] từ các thiết bị khác ngoài Floppy Disk, chẳng hạn như CD-ROM hoặc thậm chí là một ổ đĩa USB. Để giảm thiểu rủi ro an ninh liên quan đến những vấn đề này, chúng ta có thể kiện toàn hệ thống bao gồm việc đặt mật khẩu bảo vệ BIOS, kiểm soát truy cập đến môi trường vật lý của các thiết bị máy tính.

Đã có nhiều trường hợp các ổ đĩa di động không may bị mất tích. Có hai sự cố đáng chú ý đã xảy ra trong tháng 7 năm 2004, lúc đó ở tại hai phòng thí nghiệm Los Alamos National Laboratory và Sandia National Laboratory đều báo cáo bị mất các thiết bị lưu trữ có chứa thông tin mật. Điều này làm dấy lên một mối lo ngại tại Los Alamos, các cơ sở nghiên cứu quân sự hoàn toàn đóng cửa, không cho phép bất kỳ ai ra vào, cho đến khi việc tìm kiếm và điều tra được hoàn tất.

Rewaritable CD/DVDs, Mini-Disks, Optical Disks hầu như bất kỳ thiết bị lưu trữ di động nào cũng đều có thể được sử dụng để thỏa hiệp an ninh. Các công nghệ hiện đại ngày nay đã đem lại rất nhiều cơn đau đầu cho các chuyên gia bảo mật, bao gồm USB và USB gắn kèm máy nghe nhạc MP3 có khả năng lưu trữ để hàng trăm Gigabytes dữ liệu.

Bước đầu tiên trong việc phòng chống chính là cập nhật lại các Security Policies hiện có [hoặc thực hiện một cái mới hơn], bao gồm các công nghệ mới. Ngay cả ĐTDD cũng có thể kết nối đến máy tính để sao chép Data, Nhạc, Hình Ảnh, Phim ... đều này có thể đã vượt ra khỏi tầm ảnh hưởng của một chính sách bảo mật bị lỗi thời. Các công nghệ như Bluetooth, FireWire và Blackberry tất cả đều phải được đưa vào trong cuộc, khi tính toán giải quyết các vấn đề an ninh và Vulnerabilities.

Input/Output Device Management - Quản lý thiết bị Đầu Vào / Đầu Ra

Cho đến bây giờ, chúng ta đã đi qua rất nhiều vấn đề về HĐH và chúng ta không dừng lại ở đó. HĐH cũng cần phải kiểm soát tất cả các thiết bị Input/Output. Nó gửi các commands đến cho chúng, chấp nhận Interrupts của chúng khi chúng cần giao tiếp với CPU, và cung cấp Interface giữa các Devices & Applications.

I/O Devices thường được xem là Block Devices hoặc Character Devices. Block Device làm việc với các Blocks dữ liệu Fixed-Size, mỗi Block có một địa chỉ độc nhất của riêng mình. Ổ đĩa là một ví dụ về Block Device. Character Device : máy in, card mạng, chuột, bàn phím, không cần sử dụng bất kỳ Fixed Sizes nào cả. Đây là loại Data không địa chỉ [not addressable].

Khi người dùng chọn in ấn một tài liệu, mở một tập tin bằng Word hoặc save file vào ổ đĩa, những requests này đến từ Application mà người dùng đang làm việc bên trong đó, xuyên qua HĐH và đến Device được yêu cầu [requested].

HĐH sử dụng Device Driver để giao tiếp với Device Controller, nó có thể là một Circuit Card được cắm vào các slot mở rộng trên Mainboard. Controller là một thành phần điện tử với Software riêng của nó, có thể cung cấp một communication path, cho phép Device và HĐH trao đổi dữ liệu.

HĐH sẽ gửi các commands đến Registers của Device Controller và sau đó Controller sẽ ghi dữ liệu đến các thiết bị ngoại vi hoặc extracts dữ liệu được xử lý bởi CPU, tùy thuộc vào commands đó là gì. Nếu command yêu cầu Extract Data từ ổ đĩa cứng, Controller sẽ lấy các Bits và đặt chúng vào Block Size cần thiết, tiến hành thực hiện hành vi Checksum để kiểm tra tính toàn vẹn của dữ liệu. Nếu tính toàn vẹn được xác định thành công, dữ liệu sẽ được đưa vào trong Memory cho CPU tương tác với nó.

Các HĐH cần truy cập và giải phóng Devices Resources thật đúng cách. Các HĐH khác nhau sẽ quản lý việc truy cập đến Devices và Resources khác nhau. Ví dụ, Windows NTđược coi là ổn định và cung cấp môi trường xử lý dữ liệu an toàn hơn so với Windows 9x, bởi vì các Applications trong Windows NT không thể nào requests trực tiếp đến các thiết bị Hardware.

Windows NT và Windows 2000 có phương pháp kiểm soát truy cập Devices tốt hơn so với Windows 9x. Phương pháp này giúp bảo vệ HĐH khỏi những đoạn Codes tồi tệ, không đúng trong cách request và giải phóng tài nguyên. Mức độ bảo vệ này của Windows NT & Windows 2003 giúp đảm bảo Integrity và Availability cho các Resources.

Interrupts

Khi một thiết bị I/O hoàn thành bất kỳ công việc nào mà nó được giao, nó cần phải báo cho CPU biết Data cần thiết đang nằm trong Memory để xử lý. Controller của Device sẽ gửi Signal - Tín hiệu xuống Bus, Detected - được nhận biết bởi Interrupt Controller. Nếu CPU đang "busy" và Interrupt của Device không có Higher Prioprity hơn so với bất kỳ job nào đang được xử lý, khi đó Device sẽ phải chờ đợi.

Interrupt Controller gửi Message đến CPU, chỉ ra rằng Device nào cần được Attention - "Săn sóc". HĐH có một Table chứa tất cả các thiết bị I/O đã kết nối với nó, Table này được gọi là Interrupt Vector. CPU sẽ so sánh con số nhận được với giá trị bên trong bảng Interrupt Vector để nó biết xem thiết bị I/O nào cần được nó phục vụ. Table này có những Memory Addresses của các thiết bị I/O khác nhau.

Cho nên khi CPU hiểu rằng Ổ Cứng [hard drive] cần được "săn sóc", nó sẽ nhìn vào trong bảng Interrupt Vector để tìm kiếm chính xác địa chỉ Memory của ổ cứng. Đây là New Program Counter Value, đó là địa chỉ đầu tiên mà CPU cần bắt đầu việc Reading.

Một trong những mục đích chính của OS Software đó là kiểm soát hoạt động I/O mà không phụ thuộc vào thiết bị - Device Independent. Điều này có nghĩa một nhà phát triển có thể viết ra một Application để Read [mở file] hoặc để Write [save file] đến bất kỳ mọi thiết bị [floppy disk, CD-ROM, Hard-drive].

Đây là mức độ Abstraction - Trừu tượng hóa, giải phóng cho các nhà phát triển ứng dụng khỏi phải viết các Procedures khác nhau để tương tác đến các thiết bị I/O khác nhau. Nếu nhà phát triển ứng dụng đã viết một Procedure riêng cho việc ghi vào CD-Rom, một cho việc ghi vào Hard Disk, một cho việc ghi vào Floppy Disk, vân vân ... thì mỗi khi có một loại thiết bị I/O mới ra đời, tất cả các ứng dụng của nhà phát triển này bắt buộc sẽ phải được Upgraded hoặc được Patched.

Hệ Điều hành có thể thực hiện Software I/O Procedures bằng nhiều cách khác nhau. Chúng ta sẽ xem xét qua một số phương pháp sau :

• Programmed I/O • Interrupt-driven I/O • I/O using DMA • Premapped I/O • Fully mapped I/O

Programmable I/O

Nếu HĐH đang sử dụng Programmable I/O, điều này có nghĩa CPU sẽ gửi Data đến I/O Device và thăm dò Device để xem liệu nó đã sẵn sàng để chấp nhận thêm nhiều Data nữa hay chưa. Nếu thiết bị chưa sẵn sàng chấp nhận thêm Data, CPU sẽ ngồi chơi xơi nước lãng phí thời gian bằng cách chờ cho đến lúc thiết bị đó sẵn sàng.

Ví dụ, CPU sẽ gửi một Byte dữ liệu [1 ký tự] đến cho máy in, sau đó hỏi máy in xem nó đã sẵn sàng nhận một byte khác hay chưa. CPU sẽ gửi đoạn văn bản mà nó muốn in từng Byte một tại một thời điểm đến máy in. Đây là phương pháp hoạt động vô cùng chậm chạp, làm tiêu tốn mất nhiều thời gian quý giá của CPU. Vì thế cho nên, những con người thông minh kiệt xuất đã tìm ra một cách khác tốt hơn : Interrupt-Driven I/O.

Interrupt-driven I/O

Nếu HĐH đang sử dụng Interrupt-driven I/O, điều này có nghĩa CPU sẽ gửi 1 Character - Ký tự đến cho máy in, sau đó quay về thực hiện yêu cầu của Process khác. Khi máy in hoàn tất việc in ấn 1 ký tự đầu tiên, nó sẽ gửi Interrupt - Lệnh Ngắt đến CPU. CPU sẽ tạm thời dừng lại những công việc mà nó đang làm, để gửi tiếp Character thứ 2 đến cho máy in, sau đó lại quay về làm tiếp Job khác.

Quá trình này [Gửi ký tự - Quay đi làm công việc khác - Lệnh Ngắt --- Gửi ký tự khác] sẽ liên tục diễn ra cho đến khi toàn bộ đoạn văn bản được in hoàn tất. Mặc dù CPU không chờ đợi từng Byte một được in, nhưng phương pháp này cũng lãng phí thời gian trong việc xử lý tất cả các lệnh Interrupts. Cho nên lại có những đồng chí thông minh kiệt xuất hơn, nghĩ ra một phương pháp khác : I/O Using DMA.

I/O Using DMA

Direct Memory Access [DMA] - Truy Cập Bộ Nhớ Trực Tiếp là phương pháp truyền tải dữ liệu giữa các thiết bị I/O và Memory của hệ thống mà không cần sử dụng CPU. Phương pháp này giúp tăng tốc độ truyền tải dữ liệu lên đáng kể. Khi được sử dụng trong các hoạt động I/O, DMA Controller sẽ cung cấp trực tiếp các ký tự đến cho máy in mà không cần làm phiền đến CPU. Phương pháp này đôi khi còn được gọi là Unmapped I/O.

Premapped I/O

Premapped I/O và Fully Mapped I/O không liên quan đến hiệu suất giống như các phương pháp ở trên, nhưng nó cung cấp 2 phương pháp tiếp cận mà có thể trực tiếp ảnh hưởng đến vấn đề Security.

Trong hệ thống sử dụng Premapped I/O, CPU sẽ gửi Physical Memory Address của Requesting Process đến thiết bị I/O, và thiết bị I/O đủ tin cậy để tương tác trực tiếp với nội dung của Memory. Cho nên CPU sẽ không kiểm soát sự tương tác giữa I/O Device và Memory. HĐH tin tưởng thiết bị sẽ hành xử thật đúng đắn .... Điều này thật đáng sợ.

Fully Mapped I/O

Đối với hệ thống sử dụng Fully Mapped I/O, HĐH sẽ không hoàn toàn tin tưởng vào thiết bị I/O. Physical Address sẽ không được "dâng tặng" cho thiết bị I/O. Thay vào đó, thiết bị sẽ hoàn toàn làm việc với Logical Address và làm việc với "đại diện của Requesting Process. HĐH không tin tưởng thiết bị cho nên sẽ không cho phép nó tương tác trực tiếp đến Memory, thay vào đó HĐH sẽ đứng vai trò như một người môi giới để kiểm soát Device hoặc Process, xem coi chúng tương tác với nhau như thế nào.

System Architecture - Kiến Trúc Hệ Thống

Designing - Thiết kế hệ thống là một nhiệm vụ vô cùng khó khăn với nhiều mục tiêu phức tạp và trừu tượng hóa, cần phải đạt được thông qua mathematics [toán học], logic, design, programming code và triển khai thực hiện. Những quyết định thiết kế căn bản cần phải được thực hiện khi xây dựng hệ thống. Bảo mật chỉ là một trong các mục tiêu của hệ thống, nhưng nó là mục tiêu mà một chuyên gia bảo mật quan tâm nhất.

Availability, Integrity và Confidentiality có thể được thực thi tại nhiều nơi khác nhau trong tổ chức. Ví dụ, một công ty có thể lưu trữ thông tin Credit Card của khách hàng trong Database mà nhiều người dùng có thể truy cập đến. Thông tin này, rõ ràng đòi hỏi cần sự bảo vệ để đảm bảo nó không bị truy cập hoặc bị chỉnh sửa một cách trái phép.

Chúng ta nên bắt đầu với những câu hỏi chung, sau đó dần dần đi sâu vào những câu hỏi chi tiết hơn.

Cơ chế bảo vệ này nên đặt ở đâu ?

Có nên kiểm soát truy cập khi người dùng đăng nhập, chỉ ra dữ liệu nào mà họ có thể và không truy cập hay không ?

Data Files nắm giữ thông tin Credit Card có cần được bảo vệ ở mức độ File System hay không ?

Có nên cung cấp sự bảo vệ bằng cách giới hạn các hoạt động và hành vi của người dùng hay không ?

Hoặc có nên kết hợp tất cả những điều này lại với nhau hay không ?

Câu hỏi đầu tiên và phổ biến nhất chính là : Cơ chế bảo vệ này nên đặt ở đâu : ở tại phía người dùng cuối, ở nơi lưu trữ Data hay bằng cách hạn chế các hoạt động của người dùng bên trong môi trường ? Điều này được minh họa trong Figure 5-15.

Cùng một loại câu hỏi cần được giải đáp khi xây dựng Hệ Điều Hành. Một khi những câu hỏi chung này được giải đáp, vị trí của các cơ chế bảo vệ cần được giải quyết. Các cơ chế an ninh có thể được đặt ở Hardware, Kernel, OS, Services và Program Layers. Layers nào cần triển khai thực hiện các cơ chế bảo mật ?

Nếu việc bảo vệ được triển khai thực hiện tại Hardware Layer, khi đó một mức độ rộng lớn của sự bảo vệ sẽ được cung cấp, bởi vì nó cung cấp Baseline of Security cho tất cả các thành phần làm việc trên Hardware Layer. Nếu các cơ chế bảo vệ nằm gần ở phía người dùng, [Higher Levels of OS Architecture] Security sẽ được định hướng chi tiết và tập trung hơn so với các cơ chế hoạt động ở Lower Levels of OS Architecture.

Không quan trọng cơ chế bảo mật được đặt ra ở đâu trong OS Architecture, cơ chế bảo mật càng phức tạp thì mức độ Assurance - Đảm bảo nó cung cấp càng ít. Cơ chế càng phức tạp thì đòi hỏi kiến thức hiểu biết kỹ thuật càng nhiều, từ những người chịu trách nhiệm cài đặt, bảo trì và sử dụng nó. Cơ chế bảo mật càng phức tạp, thì nó càng khó khăn hơn cho việc thử nghiệm Fully Test trong mọi điều kiện có thể.

Mặt khác, các cơ chế bảo vệ đơn giản có thể không cung cấp được những chức năng và tùy chọn phong phú, mặc dù chúng dễ dàng hơn trong việc cài đặt, bảo trì, sử dụng và thử nghiệm. Cho nên việc cân bằng giữa Functionality - Chức Năng và Assurance - Đảm Bảo cần phải được hiểu thật rõ ràng để lựa chọn cơ chế bảo mật chính xác khi thiết kế hệ thống.

Sau khi các nhà thiết kế đã có ý tưởng chọn lựa cơ chế bảo vệ tập trung vào phần nào [users, operations hay data], đặt ở đâu [hardware, kernel, OS, Services hoặc Program], và mỗi cơ chế phức tạp như thế nào, họ cần phải xây dựng và tích hợp các cơ chế làm sao cho chúng tương thích với các thành phần khác của hệ thống.

Đầu tiên, Design Team - Đội ngũ thiết kế cần phải quyết định những cơ chế hệ thống nào Trust và diễn ra trong Protection Ring 0. Sau đó, đội ngũ cần phải xác định cách tương tác an toàn cho các Modules Of Code này. Mặc dù có vẻ như bạn muốn Trust tất cả các thành phần bên trong hệ thống, nhưng điều này sẽ vô cùng phức tạp, quá sức và gây ra bottlenecks cho hiệu suất.

Đối với những cơ chế được Trusted, nó cần phải thực hiện theo một cách an toàn và có thể dự đoán trước được, không gây ảnh hưởng tiêu cực đến cho những cơ chế khác. Đổi lại, những cơ chế được Trusted sẽ có quyền truy cập vào nhiều Privileged Services hơn, có quyền truy cập trực tiếp vào Memory, thường có Higher Priority khi yêu cầu CPU Processing Time và có nhiều kiểm soát hơn đối với tài nguyên hệ thống.

Vì vậy các Trusted Subjects và Trusted Objects cần phải được xác định và phân biệt với những thành phần Untrusted, cũng như xác định nơi đặt các Subsets - Tập Hợp Con này.

Defined Subsets of Subjects and Objects - Xác định các tập hợp con của Subjects và Objects

Như đã đề cập trước đây, không phải tất cả các thành phần đều cần phải được Trusted - Tin Cậy. Do đó, không phải tất cả các thành phần đều thuộc Trusted Computing Base - Nền Tảng Điện Toán Tin Cậy [TCB].

Trusted Computing Base [TCB] được định nghĩa là sự kết hợp của tất cả các cơ chế bảo vệ bên trong một hệ thống máy tính. TCB bao gồm Hardware, Software và Firmware. Đây là những thành phần của TCB, bởi vì hệ thống chắc chắn những thành phần này sẽ thực thi Security Policy và không vi phạm nó.Những thành phần nằm trong TCB cần phải được xác định [identified] và khả năng đã được chấp nhận của chúng cần phải được định nghĩa.

Ví dụ, một hệ thống mà không đòi hỏi mức độ tin cậy cao, có thể cho phép tất cả người dùng đã được xác thực, có khả năng truy cập và chỉnh sửa tất cả mọi Files trên máy tính. This Subset - Tập hợp con của các Subjects và Objects này rất lớn, mối quan hệ giữa chúng vô cùng lỏng lẻo và thoải mái.

Một hệ thống mà đòi hỏi mức độ tin cậy cao, có thể chỉ cho phép 2 Subjects có khả năng truy cập vào tất cả mọi Files trên máy tính, và chỉ cho phép một trong hai Subjects này được quyền chỉnh sửa tất cả các Files. Subset này nhỏ hơn nhiều so với Subset ở trên, và các quy định [rules] trong Subset này được thực thi nghiêm ngặt và chi tiết hơn.

Nếu Developers muốn phát triển một hệ thống mà đạt được Assurance Rating D [rất thấp] của Orange Book, khi đó những thứ tạo nên TCB sẽ không thành vấn đề, bởi vì hệ thống được dự kiến sẽ không cung cấp mức độ bảo mật cao - High Level of Security.

Tuy nhiên nếu Developers muốn phát triển một hệ thống mà đạt được Rating B2 hoặc B1 [cao hơn so với Rating D] của Orange Book, khi đó họ cần phải đảm bảo tất cả mọi thành phần của TCB đều thực hiện chính xác công việc của chúng. Những thành phần này của TCB cần phải thực thi các quy tắc nghiêm ngặt, chỉ ra cách tương tác giữa Subjects và Objects.

Developers cũng cần phải đảm bảo những thành phần này được Identified, Audited và React - Phản ứng một cách có thể dự đoán trước được, bởi vì những thành phần này sẽ được xem xét kỹ lưỡng, được kiểm tra và thẩm định trước khi đạt được Rating B2 hoặc B1. Orange Book - Sách Cam là một Evaluation Criterion - Tiêu Chí Đánh Giá, sẽ được đề cập đến trong phần The Orange Book.

Trusted Computing Base

Thuật ngữ "Trusted Computing Base" có nguồn gốc từ Orange Book, nó không đề cập đến mức độ an ninh mà một hệ thống cung cấp, thay đó nó đề cập đến Mức Độ Tin Cậy - Level of Trust mà hệ thống cung cấp, dẫu nó cùng một ý nghĩa về an ninh. Điều này bởi vì không có hệ thống máy tính nào mà có thể đảm bảo an toàn 100%. Các loại Attacks và Vulnerabilities thay đổi liên tục theo thời gian.

Nếu có đủ thời gian và nguồn lực, hầu hết các cuộc tấn công đều có thể thành công. Tuy nhiên, nếu hệ thống đáp ứng được một tiêu chí nhất định [certain criteria], nó được xem như có khả năng cung cấp một mức độ tin cậy nhất định [certain level of trust], nghĩa là nó sẽ có thể phản ứng theo một cách dự đoán trước được - React Predictably trong nhiều tình huống khác nhau.

TCB "KHÔNG CHỈ" giải quyết các thành phần của OS, vì một hệ thống máy tính "KHÔNG CHỈ" tạo nên từ duy nhất HĐH. TCB giải quyết về Hardware, Software Components và Firmware. Mỗi một thứ đều có thể gây ảnh hưởng đến môi trường của máy tính theo cách tiêu cực hoặc tích cực, và mỗi một thứ đều có trách nhiệm để hỗ trợ và thực thi Security Policy của hệ thống.

Một số thành phần và cơ chế có trách nhiệm trực tiếp trong việc hỗ trợ Security Policy, chẳng hạn như Firmware sẽ không cho phép người dùng khởi động máy tính từ một chiếc đĩa mềm, hoặc Memory Manager sẽ không cho phép các Processes ghi đè lên dữ liệu của những Processes khác. Ngoài ra, cũng có những thành phần không thực thi Security Policy, nhưng phải hoạt động đúng cách và không vi phạm độ tin cậy [Trust] của hệ thống.

Ví dụ về cách thức mà một thành phần có thể vi phạm Security Policy của hệ thống : Một Application cố gắng tạo ra Direct Call đến một Hardware, thay vì sử dụng các System Calls đúng cách thông qua HĐH, một Program cố gắng Read dữ liệu nằm ngoài Memory Space của nó, hoặc một Software không giải phóng tài nguyên đúng cách sau khi sử dụng.

TCB thường là một khái niệm rất trừu tượng đối với những người không phải là System Designers, nhiều cuốn sách và nhiều tài liệu không làm cho thuật ngữ này dễ hiểu hơn. Nếu một HĐH đang sử dụng Trusted Computing Base, điều này có nghĩa hệ thống đã được Hardened - Kiện Toàn Kernel.

Kernel được tạo nên từ Hardware, Software và Firmware, cho nên có cảm giác Kernel là TCB. TUY NHIÊN, TCB có thể bao gồm cả những thành phần khác, chẳng hạn như Trusted Commands, Programs và Configuration Files mà có thể tương tác trực tiếp với Kernel. Ví dụ khi cài đặt một hệ thống Unix, Administrator có thể lựa chọn để kích hoạt TCB trong quá trình cài đặt. Nếu TCB đã được kích hoạt [enabled], khi đó hệ thống đã có một Trusted Path, một Trusted Shell và khả năng Integrity Checking - Kiểm Tra Tính Toàn Vẹn của hệ thống.

Trusted Path là Communication Channel - Kênh giao tiếp giữa User hoặc Program và Kernel. TCB cung cấp các Protection Resources - Nguồn lực bảo vệ để đảm bảo Channel này không thể nào bị tổn hại bởi bất kỳ cách nào. Trusted Shell có nghĩa là một ai đó đang làm việc trong Shell không thể nào "Bust Out of It - Phá vỡ ra khỏi nó", và những Processes khác không thể nào "Bust Into It - Bức phá vào nó".

Một số lệnh Unix là một phần của TCB, chẳng hạn như setuid [set process ID] và setguid [set process group ID]. Chỉ có Privileged User như Root mới có khả năng thay đổi thông tin Process ID.

Các HĐH trước đây như MS-DOS, Windows 3.11 và Novell Netware 3 không có TCB. Windows 95 đã có TCB, nhưng nó chỉ có thể được sử dụng trong môi trường làm việc 32-Bit. Windows NT là phiên bản đầu tiên của Windows mà thực sự được tích hợp TCB. Microsoft sử dụng thuật ngữ "Trustworthy Computing" thay cho TCB, nhưng điều này không chỉ là khái niệm của Microsoft.

Một vài Vendors đã phối hợp cùng nhau để phát triển ra một TCB tốt hơn, bằng cách đồng ý cải tiến các phương pháp bảo vệ Software đang bị tổn thương [compromised]. Microsoft chỉ là Vendor đầu tiên thực hiện nó trong sản phẩm Windows 2003.

Mỗi HĐH đều có các thành phần riêng biệt, mà có thể gây ra nguy hiểm nghiêm trọng cho hệ thống nếu như chúng bị xâm hại. TCB cung cấp thêm Layers - Các lớp bảo vệ xung quanh những cơ chế này, nhằm giúp đảm bảo chúng không bị xâm hại, vì thế cho nên hệ thống sẽ luôn luôn vận hành một cách an toàn và có thể dự đoán trước được.

Làm thế nào để TCB thực hiện những điều kỳ diệu của nó ? Các Processes bên trong TCB là những thành phần bảo vệ cho toàn bộ hệ thống. Vì thế cho nên các nhà phát triển HĐH cần đảm bảo các Processes này phải có Own Execution Domain của riêng chúng. Có nghĩa là chúng cư trú trong Ring 0, những Instructions của chúng được thực hiện ở trạng thái Privileged State, không có bất kỳ Less Trusted Processes nào có thể tương tác trực tiếp với chúng.

Các nhà phát triển cần phải đảm bảo HĐH sẽ duy trì Isolated Execution Domain, vì các Processes của chúng không thể nào bị tổn hại hoặc bị giả mạo. Các Resources mà TCB Processes sử dụng bắt buộc cũng phải được Isolated - Cô Lập, cho nên Tigh Access Control - Kiểm soát truy cập chặt chẽ có thể được cung cấp và tất cả Access Requests và Operations có thể sẽ bị Audited.

Vì vậy về cơ bản, HĐH sẽ "nói" cho tất cả các Processes khác biết đừng "chơi" với TCB Processes và cũng đừng chơi với các Resources của TCB!

4 chức năng cơ bản của TCB chính là : Process Activation, Exexcution Domain Switching, Memory Protection, I/O Operations. Chúng ta thực sự đã đề cập qua đến tất cả những điều này trong suốt phần trước, mà không sử dụng chính xác các thuật ngữ, vì thế sau đây là một bản tóm tắt lại.

Process Activation - Kích Hoạt Tiến Trình, đề cập đến các hoạt động bắt buộc phải diễn ra khi một Process sẽ có Instructions và Data được xử lý bởi CPU. Như đã mô tả trước đây, CPU sẽ "fills - lấp đầy" các Registers của nó với thông tin về Requesting Process - Tiến Trình Đang Gửi Yêu Cầu [program counter, base and limit addresses, user or privileged mode, vân vân].

Process "activated - được kích hoạt" khi Interrupt của nó được gọi đến, cho phép nó tương tác với CPU. Process "deactivated - bị vô hiệu hóa" khi các Instructions của nó đã hoàn toàn được thực thi bởi CPU hoặc khi có một Process khác có đặc quyền cao hơn - Higher Priority gọi đến CPU. Khi Process bị Deactivated, các Registers của CPU bắt buộc phải được Filled với thông tin mới về New Requesting Process.

Dữ liệu được chuyển In và Out khỏi các Registers có thể rất nhạy cảm, cho nên các thành phần của TCB cần phải đảm bảo tất cả những điều này diễn ra một cách thật an toàn.

Một ví dụ tương tự cho dễ hiểu, giả sử có 5 người muốn nhận được lời khuyên của bạn cùng một lúc. Chỉ có duy nhất một mình bạn, cho nên mỗi người sẽ có một khoảng thời gian nhất định mà bạn có thể dành cho họ.

Người thứ 1 cung cấp cho bạn giấy tờ của cô ta, bạn có thể đọc qua chúng và tìm ra vấn đề của cô ta để cho cô ấy một câu trả lời thích hơp. Khi bạn đang đọc giấy tờ của Người thứ 1, Người thứ 2 tiến vào phòng và nói với bạn rằng anh ta là trường hợp khẩn cấp. Kết quả bạn sẽ đặt giấy tờ của Người thứ 1 xuống bàn và bắt đầu đọc giấy tờ của người thứ 2 để tìm ra vấn đề của anh ta.

Cuối cùng, có 5 người xung quanh bạn, và bạn chỉ có thể dành 5 giây cho mỗi người. Khi bạn nói chuyện với một người, bạn cần phải lấy đúng hồ sơ từ trên bàn làm việc của bạn. Những hồ sơ này có chứa thông tin nhạy cảm, cho nên bạn cần phải đảm bảo tất những hồ sơ này chính xác và đảm bảo những người này không thể đọc các hồ sơ khác không thuộc quyền sở hữu của họ.

Đây là những gì mà TCB và CPU đang thực hiện để giải quyết các Process Requests khác nhau cùng một lúc. Thay vì đọc chồng giấy tờ [stack of papers], thì CPU sẽ đọc Instructions và Data trên Memory Segment Stack.

Execution Domain Switching diễn ra khi có một Process cần gọi đến một Process khác nằm trong Higher Protection Ring - Vòng Bảo Vệ Cao Hơn. Như đã giải thích trước đây, Less Trusted Processes hoạt động trong chế độ User Mode và không thể nào thực hiện các hoạt động như giao tiếp với Hardware hoặc gửi Requests trực tiếp đến Kernel. Do đó, Process đang vận hành trong User Mode [Ring 3] bắt buộc phải tạo ra yêu cầu đến OS Service, hoạt động trong Ring 1.

Less Trusted Process sẽ nạp thông tin của nó vào trong các Registers của CPU, sau khi CPU thấy OS Service được gọi, nó sẽ Switches Domains và Security Context. Điều này có nghĩa là thông tin của OS Service Process sẽ được nạp vào trong Registers của CPU và CPU sẽ thực hiện các Instructions này trong chế độ Privileged Mode.

Vậy cho nên, Execution Domain Switching dùng để chỉ khi CPU đã thực thi các Instructions từ trong User Mode đến Privileged Mode và quay trở lại.

Memory Protection và I/O Operations đã được thảo luận trong các phần trước, do đó chúng ta chỉ cần biết rằng các hoạt động này là trách nhiệm của những thành phần trong TCB. TCB có trách nhiệm thực hiện TCB Memory Protection và I/O Operations an toàn. Nó thực hiện điều này bằng cách ngăn các hoạt động vào trong những Units riêng biệt, những Processes đó tạo nên Kernel. Điều này đảm bảo rằng nếu Kernel Process bị xâm phạm, nó cũng không có nghĩa tất cả các Processes đều nằm dưới sự kiểm soát của kẻ tấn công.

Không phải tất cả các thành phần của hệ thống đều cần được Trusted. Một phần của cuộc đánh giá Trust Level of System chính là xác định architecture, security services và assurance mechanisms mà tạo nên TCB. Trong quá trình đánh giá thẩm định, các bài kiểm tra phải thể hiện TCB được bảo vệ như thế nào từ việc giả mạo cố ý hoặc vô ý và gây ảnh hưởng đến hoạt động.

Đối với các hệ thống muốn đạt xếp hạng Trust Level cao hơn, chúng cần phải đáp ứng được các yêu cầu TCB, chi tiết Operational States của chúng, Developing Stages, Testing Procedures và Documentation sẽ được xem xét chi tiết hơn so với các hệ thống đạt xếp hạng Trust Level thấp hơn.

Bằng cách sử dụng một Specific Security Criteria - Tiêu chuẩn bảo mật cụ thể, Trust - Độ tin cậy có thể được tích hợp vào trong hệ thống, được đánh giá và chứng nhận. Cách tiếp cận này có thể cung cấp một Measurement System - Hệ Thống Đo Lường cho khách hàng sử dụng, khi cần so sánh một sản phẩm này với sản phẩm khác.

Nó cũng cung cấp cho các Vendors khuyến nghị về những gì được mong đợi đặt trên hệ thống của họ và cung cấp một Assurance Rating Metric - Số Đo Xếp Hạng Đảm Bảo, ví dụ khi một nhóm người nói về C2 Rating, tất cả mọi người đều hiểu thuật ngữ này có nghĩa là gì.

Orange Book - Sách Cam chính là một trong những Evaluation Criteria - Tiêu Chuẩn Đánh Giá. Nó xem xét tất cả các cơ chế bảo vệ của một hệ thống mà thực thi Security Policy và cung cấp một môi trường hoạt động theo cách mà nó dự kiến.

Điều này có nghĩa là mỗi Layer của hệ thống cần phải tin tưởng vào layer Underlying - Nằm bên dưới để thực hiện những chức năng đã dự kiến, cung cấp mức độ bảo vệ được mong đợi, và vận hành theo cách đã dự kiến trong nhiều tình huống khác nhau. Khi HĐH tạo ra các cuộc gọi đến Hardware, nó đoán trước rằng dữ liệu sẽ được trả về trong một Data Format cụ thể, hành xử theo một cách nhất quán và có thể dự đoán trước được.

Các Applications mà vận hành trên Top của HĐH, dự kiến có khả năng để thực hiện một System Calls nào đó, nhận được Data cần thiết trả về và hoạt động trong một môi trường Reliable - Đáng tin cậy.

Các Users mong đợi vào Hardware, OS và Applications để có thể thực hiện được những chức năng và cung cấp một mức độ nhất định của chức năng. Đối với tất cả những hành động được dự doán trước này, các yêu cầu của hệ thống cần phải được xử lý trong giai đoạn lên kế hoạch Development, chứ không phải sau này mới làm.

Security Perimeter - Vành Đai An Ninh

Như đã nêu trước đây, không phải tất cả Process và Resource đều nằm trong TCB, vì vậy những thành nằm ngoài ranh giới này được gọi là Security Perimeter - Vành Đai An Ninh. Security Perimeter là ranh giới phân chia những gì Trusted và những gì Untrusted.

Đối với hệ thống ở trong trạng thái an toàn và đáng tin cậy, Communication Standards - Các tiêu chuẩn giao tiếp nghiêm ngặt cần phải được phát triển, để đảm bảo khi một thành phần bên trong [inside] TCB cần giao tiếp với một thành phần bên ngoài [outside] TCB, thì việc giao tiếp này sẽ không thể nào bị Expose - phơi bày đối với những thỏa hiệp an ninh bất ngờ [unexpected]. Đây là loại giao tiếp được xử lý và được kiểm soát thông qua các Interfaces.

Ví dụ, Resource nằm trong ranh giới của TCB hoặc Security Perimeter bắt buộc không được cho phép các thành phần Less Trusted truy cập vào Critical System Resources. Các Processes bên trong TCB cũng cần phải cẩn thận về các Commands và Information mà chúng chấp nhận từ Less Trusted Resources. Những hạn chế và giới hạn này được tích hợp vào trong các Interfaces mà cho phép loại communication này diễn ra, cũng như được tích hợp vào trong các cơ chế thực thi Security Perimeter.

Communication giữa Trusted Components và UnTrusted Components cần được kiểm soát để đảm bảo hệ thống luôn ổn định và an toàn.Chú ý : TCB và Security Perimter không phải là các thực thể vật lý, nó là Conceptual Constructs - Cấu Trúc Khái Niệm được sử dụng bởi System Developers để phân định giữa Trusted Components và UnTrusted Components.

Reference Monitor and Security Kernel

Cho đến nay, các nhà phát triển Computer System Architecture đã thực hiện rất nhiều thứ trong việc phát triển hệ thống của họ. Họ đã xác định nơi đặt các cơ chế bảo mật [hardware, kernel, OS, services hoặc programs], các Processes bên trong TCB, cách các cơ chế bảo mật và các Processes tương tác với nhau. Họ đã xác định Security Perimeter chịu trách nhiệm phân tách các thành phần Trusted và UnTrusted. Họ đã phát triển các Interfaces phù hợp cho các thực thể này giao tiếp với nhau an toàn.

Bây giờ họ cần phải phát triển và thực hiện một cơ chế, đảm bảo rằng các Subjects truy cập đến Objects được trao cho các Permissions cần thiết để thực hiện điều đó. Điều này có nghĩa Developers phải phát triển và thực hiện Reference Monitor và Security Kernel.

Reference Monitor là một Abstract Machine - Cỗ Máy Trừu Tượng, làm trung gian cho tất cả các truy cập của Subjects đến Objects, nhằm đảm bảo các Subjects có đầy đủ Access Rights cần thiết và để bảo vệ các Objects khỏi sự truy cập, sửa đổi trái phép cũng như phá hoại. Đối với một hệ thống để đạt được Higher Level Trust, nó bắt buộc đòi hỏi các Subjects [Programs, Users, Processes] phải Fully Authorized trước khi truy cập đến Object [file, program hoặc resource].

Subject không được phép sử dụng Resource mà nó đã yêu cầu, cho đến khi Subject chứng minh nó đã được cấp quyền hạn [granted access privileges] để sử dụng Object mà nó đã requested. Reference Monitor là một Access Control Concept - Khái Niệm Kiểm Soát Truy Cập, không phải là một thành phần vật lý, đó là lý do tại sao nó thường được gọi là Reference Monitor Concept hoặc Abstract Machine.

Security Kernel được tạo nên bởi các thành phần Hardware, Software và Firmware thuộc TCB, nó triển khai và thực thi Reference Monitor Concept. Security Kernel làm trung gian cho tất cả các truy cập và chức năng giữa Subjects và Objects. Security Kernel là Core của TCB và thường được sử dụng phổ biến nhất để xây dựng Trusted Computing Systems. Security Kernel có 3 yêu cầu chính :

• Nó phải cung cấp Isolation - Sự Cô Lập cho các Processes đang thực hiện Reference Monitor Concept và các Processes cần phải được Tamper-proof - Chống lục lọi, trộm cắp.

• Nó phải được Invoked - Gọi đến cho tất cả những sự truy cập và phải có khả năng không bị phá vỡ. Do đó, Security Kernel cần được triển khai một cách đầy đủ và rõ ràng.

• Nó phải đủ nhỏ để được kiểm tra và thử nghiệm theo một cách đầy đủ và toàn diện.

Đây là những yêu cầu của Reference Monitor; Do đó, chúng là những yêu cầu của các thành phần mà cung cấp và thực thi Reference Monitor Concept----Security Kernel.

Những vấn đề này hoạt động theo một cách trừu tượng hóa, nhưng được triển khai trong thế giới vật lý bằng thiết bị Hardware và Software Code. Việc đảm bảo các thành phần thực thi ý tưởng trừu tượng của Reference Monitor được cung cấp thông qua Testing và Functionality.

Chú ý : Reference Monitor là Concept trong một Abstract Machine, làm trung gian cho tất cả các truy cập từ Subjects đến Objects. Security Kernel là Hardware, Firmware và Software của TCB để thực hiện Concept này. TCB là toàn bộ các cơ chế bảo vệ bên trong một hệ thống máy tính, phối hợp với nhau để thực thi Security Policy. TCB chứa Security Kernel và tất cả các cơ chế bảo vệ khác.

Security Policy

Như đã nói qua trước đây, TCB chứa các thành phần trực tiếp thực thi Security Policy, như vậy thì Security Policy là gì ? Security Policy - Chính sách bảo mật tập hợp các Rules - Quy Tắc và Practices - Thực Hành, chỉ ra cho biết thông tin nhạy cảm và tài nguyên được managed, được protected và distributed như thế nào.

Security Policy thể hiện chính xác mức độ bảo mật, bằng cách thiết lập các mục tiêu mà các cơ chế bảo vệ có nghĩa vụ phải hoàn thành. Đây là một yếu tố quan trọng có vai trò thiết yếu trong khi xác định thiết kế hệ thống. Security Policy là nền tảng cho chi tiết kỹ thuật [specifications] của hệ thống và cung cấp Baseline để đánh giá hệ thống.

Domain Information Security & Risk Management đã nói rất nhiều về Security Policy, nhưng những chính sách đó chủ yếu là hướng vào chính bản thân tổ chức của chúng ta. Các chính sách bảo mật mà chương này đề cập đến là dành cho OS và Applications. Các chính sách cũng tương tự nhau nhưng có những mục tiêu khác nhau : Một tổ chức sẽ đối lập rất nhiều so với một hệ thống máy tính.

Hệ thống cung cấp sự tin cậy bằng cách thực thi Security Policy và giám sát việc giao tiếp giữa Subjects và Objects. Chính sách phải chỉ ra cho biết Subjects nào có thể truy cập đến Objects nào, những hành vi nào được chấp nhận [acceptable] và không thể chấp nhận [unacceptable]. Chính sách bảo mật cung cấp Framework - Nền tảng cho Security Architecture - Kiến trúc an ninh của hệ thống.

Đối với hệ thống để cung cấp một Mức độ tin cậy chấp nhận được - Acceptable Level of Trust, nó phải dựa trên kiến trúc để cung cấp các khả năng bảo vệ chính bản thân nó khỏi Untrusted Processes, những sự thỏa hiệp do vô tình hoặc cố ý, cũng như các cuộc tấn công ở các Layers khác nhau của hệ thống. Đa số các Trust Rating - Xếp Hạng Độ Tin Cậy, được thu thập thông qua những cuộc thẩm định, đòi hỏi xác định Subset of Subjects & Objects, Explicit Domains và Isolation of Processes để việc truy cập đến chúng có thể được kiểm soát và các hoạt động có thể được Audited.

Hãy tái hợp lại nào !

Chúng ta biết rằng Độ Tin Cậy của một hệ thống được xác định bằng cách nó thực thi Security Policy của nó như thế nào. Khi hệ thống được thử nghiệm với các tiêu chí cụ thể, nó sẽ được gán một mức Rating nào đó và Rating này được sử dụng bởi khách hàng, Vendors, các tổ chức máy tính, vân vân.

Criteria - Tiêu chí sẽ được xác định nếu Security Policy đang được hỗ trợ và thực thi. Security Policy đưa ra các Rules và Practices liên quan đến cách quản lý, bảo vệ hệ thống và cho phép truy cập đến các nguồn tài nguyên nhạy cảm. Reference Monitor là một Concept, tuyên bố rằng tất cả các Subjects phải có sự ủy quyền thích hợp mới có thể truy cập đến Objects, và Concept này được triển khai thực hiện bằng Security Kernel.

Security Kernel bao gồm tất cả các Resources giám sát hoạt động của hệ thống theo quy định của Security Policy thuộc hệ thống, và là một phần của HĐH chịu trách nhiệm kiểm soát truy cập đến tài nguyên hệ thống. Để Security Kernel hoạt động chính xác, cá nhân các Processes phải được Isolated và các Domains phải được xác định để chỉ ra Objects nào availaible cho Subjects nào.

Security Policies ngăn chặn thông tin từ dòng chảy High Security Level xuống đến Lower Security Level được gọi là Multilevel Security Policies. Những loại chính sách này cho phép Subject truy cập đến Object CHỈ KHI Security Level của Subject cao hơn hoặc bằng với Classification của Object.

Như đã nói qua trước đây, các Concepts được đề cập trong những phần trước là những Abstract Ideas - Ý Tưởng Trừu Tượng, sẽ được "thể hiện" trong các thành phần Physical Hardware, Firmware, Software Code và các hoạt động thông qua Designing, Building và Implementing hệ thống. Những Ideads này giống như những mục tiêu trừu tượng và giấc mơ mà chúng ta thường mong muốn đạt được, bằng cách làm việc chăm chỉ và tuân thủ kỷ luật.

Least Privilege - Đặc Quyền Ít Nhất

Sau khi các Resources và Processes đã được cô lập thích hợp [isolated properly], Least Privilege cần được thực thi. Điều này có nghĩa là một Process không được phép có đặc quyền quá mức cần thiết để có thể hoàn thành các chức năng của nó. Chỉ những Processes cần thực hiện các chức năng hệ thống Critical mới được cho phép, Less Privileged Processes cần gọi đến More Privileged Processes để thực hiện các hoạt động này khi cần thiết.

Đây là loại hoạt động gián tiếp bảo vệ hệ thống khỏi những đoạn Code bị viết cẩu thả, nghèo nàn. Các Processes cần sở hữu một mức độ Privilege chỉ khi chúng thực sự cần đến nó.

Nếu Process cần Status của nó được nâng cao [elevated] để nó có thể tương tác trực tiếp với tài nguyên hệ thống, khi nhiệm vụ của nó hoàn thành thì Status của Process cần Dropped - Được giảm xuống đặc quyền thấp hơn [lower privileged] để đảm bảo các cơ chế khác không thể sử dụng nó gây ảnh hưởng tiêu cực cho hệ thống. Các Processes cần đầy đủ System Privileges được đặt trong Kernel. Các Process khác ít đặt quyền hơn sẽ gọi đến chúng để xử lý các hoạt động nhạy cảm.

Một ví dụ về Least Privilege Access Control : System Backup Program có thể Read Access vào các Files, nhưng nó không cần quyền chỉnh sửa Files. Tương tự, System Restore Program có thể cần được cho phép Write Files vào ổ cứng nhưng nó không cần đọc các Files này.

Security Models

Một khái niệm quan trọng trong việc thiết kế và phân tích tính an toàn của hệ thống chính là Security Model - Mô Hình Bảo Mật, bởi vì nó chính là sự kết hợp - incorporates các Security Policy cần được thực thi trong hệ thống. Model là một Symbolic Representation- Đại Diện Biểu Tượng của Policy. Nó ánh xạ mong muốn của những người hoạch định chính sách vào một tập hợp các quy tắc - set of rules mà hệ thống máy tính bắt buộc phải tuân theo.

Lý do mà chương này đã nhiều lần nhắc đi nhắc lại về Security Policy là bởi vì nó là một thuật ngữ trừu tượng, đại diện cho các mục tiêu và mục đích mà một hệ thống bắt buộc phải đáp ứng và hoàn thành, khi đó hệ thống mới được xem là an toàn và có thể chấp nhận được. Làm thế nào để chúng ta có thể từ một chính sách bảo mật mà thực thi được khả năng : Administrator "uncheck box" trên GUI để không cho phép Anh Tèo truy cập vào các files quan trọng trên hệ thống của anh ta ?

Có rất nhiều bước phức tạp giữa lúc diễn ra thiết kế và phát triển hệ thống.

Security Model ánh xạ các Abstract Goals - Mục Tiêu Trừu Tượng của chính sách đến hệ thống thông tin, bằng cách xác định Explicit Data Structures - Cấu trúc dữ liệu rõ ràng và các kỹ thuật cần thiết để thực thi Security Policy. Security Model thường được thể hiện trong toán học và các ý tưởng phân tích, nó ánh xạ đến các chi tiết kỹ thuật và sau đó được phát triển bởi các nhà lập trình viên thông qua lập trình mã.

Cho nên ví dụ chúng ta có một chính sách bao gồm những mục tiêu an ninh chẳng hạn như : "Mỗi Subject bắt buộc phải được authorized để truy cập đến từng Object." Security Model sẽ giữ yêu cầu này và cung cấp các công thức toán học cần thiết, relationships và structures để hoàn thành được mục tiêu này.

Từ đó, Specifications - Các chi tiết kỹ thuật được phát triển cho từng loại HĐH [Unix, Windows, Macintosh, vân vân] và cá nhân từng Vendors có thể quyết định họ sẽ thực hiện các cơ chế như thế nào để đáp ứng được những yêu cầu kỹ thuật cần thiết này.

Có một ví dụ rất chung chung và đơn giản như sau : Nếu Security Policy tuyên bố rằng các Subjects cần phải được authorized để truy cập đến Objects, Security Model sẽ cung cấp Relationships - Mối Quan Hệ và Formulas - Công thức toán học để giải thích "Làm thế nào X có thể truy cập đến Y thông qua các phương pháp cụ thể". Specifications sau đó sẽ được phát triển để cung cấp một cầu nối những gì diễn ra trong môi trường máy tính và làm thế nào nó ánh xạ các thành phần này lại với nhau.

Các nhà lập trình viên khi đó sẽ viết ra một chương trình để tạo ra các cơ chế cung cấp cách thức cho hệ thống, sử dụng ACLs [Access-control-lists] và giao cho Administrator một số mức độ kiểm soát. Cơ chế này cung cấp cho Administrator một GUI - Giao Diện Đồ Họa cho phép anh ta lựa chọn [thông qua Check Boxes chẳng hạn] Subjects nào có thể truy cập đến Objects nào và có thể thiết lập cấu hình này bên trong Hệ Điều Hành.

Trên đây là một ví dụ rất đơn giản, bởi vì Security Model có thể rất phức tạp, nhưng nó được sử dụng để chứng minh mối quan hệ giữa Security Policy và Security Model.

Một số Security Models, chẳng hạn như Bell-LaPadula Model, thực thi các quy tắc để cung cấp sự bảo vệ cho Confidentiality - Tính Bảo Mật. Các Models khác, chẳng hạn như Biba Model, thực thi các quy tắc để cung cấp sự bảo vệ cho Integrity. Formal Security Models - Các mô hình bảo mật chính thức, chẳng hạn như Bell-LaPadula và Biba được sử dụng để cung cấp một độ đảm bảo cao [high assurance] về mặt an ninh. Informal Models - Các mô hình bảo mật không chính thức, chẳng hạn như Clark-Wilson được sử dụng như một Framework để mô tả cách thức thực hiện Security Policies.

Security Policy đưa ra các mục tiêu mà không quan tâm chúng sẽ được thực hiện như thế nào. Model là một Framework cung cấp hình thức cho Policy và giải quyết Security Access Problems cho các tình huống cụ thể. Một số Security Models được phát triển để thực thi các chính sách bảo mật. Những phần sau đây sẽ giới thiệu tổng quan về các Security Models.

State Machine Models

Trong State Machine Models, để Verify - Xác minh sự an toàn của một hệ thống thì State được sử dụng, có nghĩa là tất cả các Current Permissions và tất cả các Current Instances của Subjects đang truy cập đến Objects bắt buộc phải được Captured. Maintaining - Việc duy trì trạng thái của một hệ thống là để xử lý từng liên kết của Subject với Objects. Nếu Subjects có thể truy cập đến Objects mà trùng khớp với Security Policy, hệ thống được an toàn.

State Machines đã cung cấp một nền tảng cơ bản cho các Security Models quan trọng. State - Trạng thái của một hệ thống nghĩa là Snapshot của hệ thống tại một thời điểm nào đó. Rất nhiều hoạt động có thể làm thay đổi State này, được gọi là State Transitions - Chuyển Trạng Thái.

Các nhà phát triển HĐH thực hiện State Machine Model, cần phải xem xét tất cả các Different State Transitions - Quá trình chuyển đổi trạng thái khác nhau, mà có thể xảy ra và đánh giá xem liệu một hệ thống đã được khởi động trong Secure State - Trạng Thái An Toàn, có thể bị đưa vào một Insecure State bởi bất kỳ những sự kiện này hay không. Nếu tất cả những hoạt động được phép xảy ra trong hệ thống không làm tổn thương và không đưa hệ thống vào trạng thái Insecure State, khi đó hệ thống sẽ thực hiện một Secure State Machine Model.

State Machine Model được sử dụng để mô tả hành vi của hệ thống đối với những Inputs khác nhau. Nó cung cấp các cấu trúc toán học đại diện cho các tập hợp [subjects & objects] và Sequences - Trình tự.

Khi Object chấp nhận một Input, điều này sẽ làm thay đổi State Variable - Biến Trạng Thái. Một ví dụ đơn giản về State Variable là Name, Value được mô tả trong Figure 5-16. Variable này là một phần Instruction Set của HĐH. Khi Variable này được gọi đến để sử dụng, nó có thể được đưa vào giá trị Color, Red từ Input của người dùng hoặc chương trình. Giả sử người dùng nhập vào một giá trị khác, bây giờ Variable sẽ là Color, Blue.

Trên đây là một ví dụ đơn giản về State Transition. Một số State Transition này tuy đơn giản nhưng sẽ trở nên phức tạp khi hệ thống cần ra quyết định xem Transition này có nên được cho phép hay không. Để Transition này được cho phép, Security Attributes của Object và Access Rights của Subjects bắt buộc phải được xem xét và được cho phép bởi HĐH.

Các nhà phát triển, những người thực hiện State Machine Model bắt buộc phải xác định tất cả các Initial States - Trạng thái ban đầu [default variable vaules] và phát thảo ra cách có thể thay đổi những Values này [các Inputs sẽ được chấp nhận] để các Final States vẫn đảm bảo hệ thống được an toàn. Việc phát thảo ra cách thay đổi những Values thường được thực hiện thông qua Condition Statements : "If condition then update"

Một hệ thống đã sử dụng State Machine Model sẽ được ở trong Secure State trong mọi trường hợp. Nó sẽ khởi động vào Secure State, thực hiện các commands và các transactions an toàn, cho phép Subjects truy cập đến Resources chỉ trong Secure State, và Shutdown nếu không ở trong Secure State. Failing - Không ở trong Secure State là một vấn đề vô cùng quan trọng !

Nó bắt buộc rằng nếu bất cứ điều gì không an toàn xảy ra, hệ thống cần phải "cứu lấy chính mình" và không làm cho bản thân bị tổn thương. Khi HĐH hiển thị một thông báo lỗi đến người dùng hoặc Reboots hoặc treo máy, nghĩa là nó đang thực hiện biện pháp Safety - An Toàn.

HĐH đã có kinh nghiệm biết được rằng một điều gì đó bị xem là bất hợp pháp và nó không thể tự "chăm sóc" chính bản thân mình trong trường hợp đó, cho nên để đảm bảo nó không rơi vào Insecure State, nó phản ứng lại bằng một trong những cách reboot, thông báo lỗi, treo máy ... Do đó, nếu Application hoặc hệ thống bị treo, chúng ta hãy hiểu đơn giản rằng hệ thống đang cố gắng bảo vệ chính bản thân nó và dữ liệu của chúng ta.

Có một số điểm cần phải được xem xét khi phát triển sản phẩm có sử dụng State Machine Model. Trước tiên, nhà phát triển phải xác định xem những gì và như thế nào là State Variables - Biến Trạng Thái. Trong môi trường máy tính, tất cả Data Variables độc lập có thể được xem là State Variables và sự thay đổi không phù hợp có thể khiến cho hệ thống bị hỏng hoặc ảnh hưởng tiêu cực đến hoạt động của Process khác.

Kế tiếp, nhà phát triển phải xác định Secure State cho mỗi State Variable. Bước tiếp theo nữa là xác định những State Transition Functions được cho phép. Các Functions này sẽ mô tả những sự thay đổi được cho phép có thể được thực hiện đối với State Variables.

Sau khi State Transition Functions được xác định, chúng phải được kiểm tra để xác minh tổng thể Machine State sẽ không bị tổn hại và những Transition Functions này sẽ giữ cho sự toàn vẹn của hệ thống [computer, data, program, process..] luôn luôn nguyên vẹn.

The Bell-LaPadula Model

Trong những năm 1970, quân đội Hoa Kỳ đã sử dụng hệ thống Time-Sharing Mainframe, cũng như đã có sự quan ngại đến vấn đề bảo mật của những hệ thống này, vấn đề rò rỉ thông tin bí mật. Bell-LaPadula Model ra đời để giải quyết những mối ngại này.

Bell-LaPadula Model là Mathematical Model - Mô Hình Toán Học đầu tiên của một chính sách bảo mật đa cấp - multilevel security policy, được sử dụng để định nghĩa khái niệm về Secure State Machine và Mode of Access và đưa ra các quy tắc cho việc truy cập. Sự phát triển của nó được tài trợ bởi chính phủ Hoa Kỳ nhằm cung cấp một nền tảng cho các hệ thống máy tính sẽ được sử dụng để lưu trữ và xử lý thông tin nhạy cảm. Mục tiêu chính của Model này chính là để ngăn việc chia sẻ và truy cập thông tin bí mật một cách trái phép.

Hệ thống sử dụng Bell-LaPadula Model được gọi là Multilevel Security System - Hệ Thống Bảo Mật Đa Cấp, bởi vì người dùng với những Clearances khác nhau cùng sử dụng hệ thống, và hệ thống xử lý những Data có Classifications khác nhau. Cấp độ thông tin được phân loại sẽ xác định các Handling Procedures - Thủ tục xử lý cần được sử dụng. Bell-LaPadula Model là một State Machine Model, chịu trách nhiệm thực thi khía cạnh an ninh Confidentiality trong việc kiểm soát truy cập.

Matrix và Security Levels được sử dụng để xác định nếu các Subjects có thể truy cập đến các Objects khác nhau. Clearance của Subject được so sánh với Classification của Object, sau đó những quy tắc cụ thể sẽ được áp dụng để kiểm soát việc tương tác giữa Subject và Object.

Model này sử dụng Subjects, Objects, Access Operations [read, write and read/write] và Security Levels. Subjects và Objects có thể trú ngụ ở những Security Levels khác nhau, sẽ có Relationships và các quy tắc chỉ ra những hoạt động được phép giữa chúng. Model này khi được thực hiện và thi hành đúng cách, đã được chứng minh toán học là có thể cung cấp một Hệ Điều Hành vô cùng an toàn và hiệu quả. Nó còn là một Information-flow Security Model, có nghĩa là thông tin không bao giờ "chảy" một cách không an toàn.

Bell-LaPadula Model là một Subject-to-Object Model. Ví dụ chúng ta [Subject] có thể đọc một phần dữ liệu [Object] từ một Database nào đó và có thể Write dữ liệu vào trong Database đó. Bell-LaPadula Model tập trung chủ yếu vào việc đảm bảo các Subjects được authenticated đúng cách—bằng cách có Security Clearance cần thiết, need to know và sự phê duyệt cho phép truy cập—trước khi có thể truy cập vào một Object.

Có 3 quy tắc chính được sử dụng và thực thi trong Bell-LaPadula Model :

1. Simple Security Rule - Quy tắc an ninh cơ bản [No Read-Up] 2. *-Property Rule hay còn gọi là Start Property Rule - Quy tắc đặc tính ngôi sao [No Write-Down] 3. Strong Star Property Rule - Quy tắc đặc tính ngôi sao mạnh mẽ [Clearance = Classification]

Simple Security Rule tuyên bố rằng một Subject trong một Security Level nhất định không được phép Read dữ liệu nằm ở mức độ Security Level cao hơn [higher]. Ví dụ, nếu Anh Ba Khía có Security Clearance là Secret, quy tắc này tuyên bố rằng anh Ba Khía sẽ không Read được Data có Classification là Top Secret. Nếu tổ chức muốn anh Ba Khía có thể Read được Top-secret Data, họ phải giao cho anh Ba Khía cấp độ Clearance đó ngay từ lúc đầu.

*-Property Rule tuyên bố rằng một Subject trong một Security Level nhất định không được phép Write dữ liệu nằm ở mức độ Security Level thấp hơn [Lower]. Cho nên Simple Security Rule thường được gọi là "No Read Up - Không Đọc Lên" Rule, và *-Property Rule thì được gọi là "No Write Down - Không Ghi Xuống" Rule.

Strong Star Property Rule tuyên bố rằng một Subject chỉ có thể Read và Write đối với những Object nằm ở cùng một Security Level, không cao hơn cũng không thấp hơn. Cho nên đối với quy tắc thứ 3 này, để Subject có thể Read và Write đến một Object, Clearance và Classification của "hai đứa" bắt buộc phải ngang nhau.

3 Quy Tắc này chỉ ra cho biết những trạng thái [States] nào hệ thống có thể đi vào. Hãy nhớ rằng State chính là giá trị của các Variables trong Software tại Snapshot trong một thời điểm. Nếu Subject đã thực hiện Read Operation đến một Object nằm ở Lower Security Level, Subject giờ đây đã có một Variable "populated - được phổ biến" với Data đã được Read hoặc được Copied vào trong Variable của nó. Nếu Subject đã Written đến một Object nằm ở Higher Security Level, Subject đã modified Variable nằm bên trong Domain của Object.

Chú ý : Trong Access Control Terms - Thuật Ngữ Kiểm Soát Truy Cập, Dominate có nghĩa là "Higher Than - Cao Hơn" hoặc "Equal to - Bằng". Cho nên nếu bạn thấy một phát biểu chẳng hạn như : "Subject chỉ có thể thực hiện Read Operation nếu Access Class của Subject dominates với Access Class của Object", điều này có nghĩa là Subject bắt buộc phải có Clearance cao hơn hoặc bằng với Classification của Object. Trong Bell-LaPadula Model, điều này được gọi là Dominance Relation, nghĩa là mối quan hệ Clearance của Subject đối với Classification của Object.

State của một hệ thống sẽ thay đổi khi có các hoạt động khác nhau diễn ra. Bell-LaPadula Model định nghĩa một Secure State, nghĩa là một môi trường Secure Computing - Điện Toán An Toàn và những hành động allowed - được cho phép, đó là những hành động security-perserving - bảo toàn được trạng thái an ninh của hệ thống. Điều này có nghĩa là Model sẽ cung cấp một Secure State và chỉ có những Operations được cho phép mới giữ cho hệ thống nằm được ở Secure State, không làm cho hệ thống rơi vào Insecure State.

Vì vậy nếu có 100 người access đến 2000 Object trong một ngày bằng cách sử dụng 1 hệ thống, hệ thống này sẽ phải thông qua rất nhiều tác vụ [work] và các hoạt động rất phức tạp sẽ diễn ra. Tuy nhiên vào cuối ngày, hệ thống vẫn Secure như thời điểm bắt đầu trong ngày. Đây là định nghĩa của Basic Security Theorem - Định Lý Bảo Mật Cơ Bản, được sử dụng trong khoa học máy tính, trong đó nêu rằng : Nếu một hệ thống được khởi tạo trong Secure State và tất cả các Allowed State Transitions đều Secure, khi đó tất cả Subsequent State - Trạng Thái Xảy Ra Sau đều sẽ được Secure, không quan tâm Inputs là gì.Chú ý : Tranquility Principle - Nguyên Tắc Tĩnh Lặng cũng được sử dụng trong Model này, nghĩa là Subjects và Objects không thể thay đổi Security Levels của nó một khi chúng đã được khởi tạo ra. Chú ý : Việc đảm bảo thông tin "not flow - không chảy" từ Higher Security Level xuống Lower Security Level được gọi là Controlling Unauthorized Downgrading of Information - Kiểm Soát "Sự Xuống Cấp" Thông Tin Trái Phép, sẽ diễn ra thông qua "Write Down" operation. Một sự thỏa hiệp thực tế sẽ diễn ra nếu User tại Lower Security Level "đọc" dữ liệu này.

Một điều quan trọng cần lưu ý đó là Bell-LaPadula Model đã được phát triển để đảm bảo tính bí mật; Do đó, nó chỉ cung cấp và giải quyết vấn đề Confidentiality. Model này không giải quyết vấn đề Integrity của Data, Model này chỉ quan tâm Ai có thể và không thể truy cập đến Data, cũng như những hoạt động nào có thể được diễn ra.

Vậy điều này có nghĩa là gì và tại sao nó quan trọng ? Domain Access Control đã thảo luận về MAC - Mandatory Access Control System với DAC - Discretionary Access Control System. Tất cả hệ thống MAC đều dựa trên Bell-LaPadula Model, bởi vì nó cho phép Multilevel Security được tích hợp vào bên trong Code. Subjects và Objects được assigned labels - gán nhãn.

Label của Subject chứa Clearance Label của nó [top secret, secret hoặc confidential] và Label của Object chứa Classification Label của nó [top secret, secret, hoặc confidential]. Khi Subject truy cập vào Object, hệ thống sẽ so sánh Clearance Label của Subject và Classification Label của Object và nhìn vào Matrix để xem xét nếu điều này hợp pháp và là hoạt động an toàn. Trong kịch bản của chúng ta, nó là một hoạt động hoàn toàn an toàn, vậy là Subject được quyền tiếp cận Object.

Bây giờ, nếu Clearance Label của Subject là Top Secret và Classification Label của Object là Secret, thì Subject sẽ không thể nào Write vào Object này, bởi vì *-Property Rule ! Quy tắc này nhằm đảm bảo Subjects không thể nào cố tình hoặc vô ý chia sẻ thông tin Confidential bằng việc Writting đến một Object ở Lower Security Level.

Giả sử có một ông tướng quân vụng về [người có Top-secret Clearance] trong quân đội, mở một lá thư có lệnh chỉ thị [lá thư này có Classification là Secret] gửi đi cho tất cả các thư ký ở tất cả các cơ sở khắp toàn thế giới. Tướng quân cố gắng viết rằng quân đội Hoa Kỳ đang tấn công vào Cuba. Bell-LaPadula Model sẽ hành động ngay lập tức, không cho phép vị tướng quân này ghi thông tin đó vào loại tập tin này, bởi vì Clearance của tướng quân cao hơn so với Classification của Memo [thông báo].

Tương tự như trên, nếu người thư ký quân đội cố gắng đọc Memo mà chỉ dành cho các vị tướng quân hoặc các chỉ huy cấp cao hơn anh ta, Bell-LaPadula Model cũng sẽ lập tức "stop" hành động này lại. Clearance của người thư ký thấp hơn so với Classification của Object [memo], và điều này vi phạm vào Simple Security Rule của Model. Đó là tất cả những gì phục vụ cho mục đích đảm bảo Confidently.Chú ý : Điều quan trọng là Hệ Điều Hành MAC và MAC Databases phải tuân thủ theo những quy tắc này. Trong Domain : Application Security, chúng ta sẽ xem xét làm thế nào Databases có thể tuân thủ theo những quy tắc này bằng cách sử dụng Polyinstantiation.

Chú ý : Chúng ta có thể rơi vào Bell-LaPadula Rule được gọi là Discretionary Security Property [DS-Property], nó là một loại Property khác trong Model này. Quy tắc này dựa trên tên của Subjects và Objects. Nó chỉ định các Permissions cụ thể cho phép Subject pass - vượt qua các Permissions theo quyết định của riêng mình [own discretion]. Những Permissions này được lưu trữ trong Access Matrix. Điều này có nghĩa là cả hai cơ chế MAC và DAC có thể được triển khai thực hiện trên cùng một HĐH.

The Biba Model

Biba Model được phát triển sau Bell-LaPadula Model. Nó là một State Machine Model, rất giống với Bell-LaPadula Model. Biba tập trung giải quyết những vấn đề về Integrity của Data trong các Applications. Bell-LaPadula Models sử dụng Lattice - Một dàn Security Levels [top secret, secret, sensitive, vv...]. Những Security Levels này đã được phát triển chủ yếu để đảm bảo rằng các dữ liệu Sensitive chỉ available với những cá nhân đã được Authorized.

Biba Model không quan tâm đến Security Levels và Confidentiality ! Biba Model sử dụng một dàn Integrity Levels.

Nếu được triển khai thực hiện và thi hành đúng cách, Biba Model sẽ giúp ngăn chặn [prevent] Data từ bất kỳ Integrity Level "flowing - chảy" đến một Higher Integrity Level. Biba có 3 Rules chính để cung cấp loại bảo vệ này :

1. *-Integrity Axiom hay còn gọi là Star Integrity Axiom : Subject không thể Write dữ liệu đến một Object nằm ở Higher Integrity Level - Cấp Độ Toàn Vẹn Cao Hơn [còn gọi là "No Write Up - Không Ghi Lên"].

2. Simple Integrity Axiom : Subject không thể Read dữ liệu từ một Lower Integrity Level - Cấp Độ Toàn Vẹn Thấp Hơn [còn gọi là "No Read Down - Không Đọc Xuống].

3. Invocation Property : Subject không thể Request Service - Yêu Cầu Dịch Vụ [invoke - gọi] đến một Subjects nằm ở Higher Integrity. Chú ý trong quy tắc này là Subject-to-Subject nhé !

Tên gọi "Simple Integrity Axiom" nghe có vẻ hơi ngốc ngếch chút, nhưng quy tắc này bảo vệ cho Subject và Data ở Higher Integrity Level khỏi sự hỏng hóc gây ra bởi Data ở Lower Integrity Level. Đây là tất cả những gì về Trusting - Sự Tin Cậy vào nguồn gốc của thông tin. Trusted Data thì Data nó "clean - sạch", còn đối với Untrusted Data [từ một Lower Integrity Level] thì Data nó "dirty - bẩn". Dirty Data không nên trộn lẫn với Clean Data, bởi vì điều đó có thể hủy hoại tính toàn vẹn của Clean Data.

Simple Integrity Axiom được áp dụng không chỉ cho Subjects tạo ra Data, mà còn cho các Processes. Process của Lower Integrity Level không nên được Writting đến Trusted Data của Higher Integrity Level. Những khu vực của các Integrity Levels khác nhau được ngăn bên trong Application đó là dựa trên Biba Model.

Một ví dụ tương tự : Nếu bạn đang viết bài cho chuyên mục Blog của DucNguyenA.com về xu hướng bảo mật trong năm qua, thiệt hại tài chính của các doanh nghiệp, tỷ lệ cost/benefit trong việc triển khai Firewalls, IPSs và Vulnerability Scanners. Bạn sẽ không muốn thu thập dữ liệu và số liệu từ bất kỳ Web site nào mà bạn không biết số liệu đó được tính toán ra sao, cũng như nguồn gốc của thông tin. Bài viết của bạn [Dữ liệu nằm ở Higher Integrity Level] có thể bị tổn hại nếu bạn "trộn" nó với những thông tin vô căn cứ từ những nguồn thông tin xấu [Dữ liệu nằm ở Lower Integrity Level].

Lần đầu tiên khi bạn tìm hiểu về Bell-LaPadula và Biba Models trông chúng có vẻ rất giống nhau, nhưng thực sự chúng có những sự khác biết có thể hơi khó hiểu. Bell-LaPadula Model được phát triển dành cho Chính Phủ Hoa Kỳ và chính phủ rất hoang tưởng [paranoid] về sự rò rỉ thông tin bí mật của họ. Trong Model của họ, người dùng không được Write đến Lower Level bởi vì người dùng có thể làm tiết lộ một số bí mật Secrets.

Tương tự, người dùng ở Lower Level không được Read bất cứ điều gì ở Higher Level bởi vì người dùng có thể "đọc lén" một số bí mật Secrets. Tuy nhiên, không phải tất cả mọi người đều bận tâm về Confidentiality và không phải ai cũng có Secrets thật bự để bảo vệ. Các ngành công nghiệp thương mại quan tâm phần lớn về Integrity trong Data của họ.

Các công ty kế toán lại càng quan tâm về tính chính xác của những con số, cũng như đảm bảo không bỏ sót bất kỳ "dấu phẩy" nào trong quá trình được thực hiện bởi Application. Các công ty kế toán rất quan tâm về Integrity của những dữ liệu này và thường phải chịu sự đe dọa nho nhỏ của một người nào đó đang cố gắng để ăn cắp những con số này, vì vậy các công ty kế toán sẽ sử dụng phần mềm dùng Biba Model. Tất nhiên, các công ty kế toán không nhìn thấy tên Biba trong sản phẩm của họ hoặc đảm bảo nó được thiết kế trong Application của họ.

Assurance Ratings - Xếp hạng độ đảm bảo là những gì mà người dùng sử dụng để xác định xem hệ thống có phù hợp với họ hay không. Vì vậy, ngay cả khi các kế toán đang sử dụng Application có áp dụng Biba Model, họ sẽ không nhất thiết phải biết điều đó [tất nhiên chúng ta sẽ không nói cho họ biết!].

Invocation Property trong BiBa Model tuyên bố rằng, Subject không thể invoke [gọi] đến một Subject nằm ở Higher Integrity Level. Vậy nó khác gì so với 2 quy tắc còn lại của Biba ? *-Integrity Axiom [no write up] chỉ ra cho biết Subjects có thể modify - sửa đổi Objects như thế nào. Simple Integrity Axiom [no read down] chỉ ra cho biết Subjects có thể read - đọc Objects như thế nào. Invocation Property chỉ ra cho biết cách một Subject communicate - giao tiếp và initialize - khởi tạo một Subjects khác tại thời điểm chạy [run time].

Một ví dụ về việc Subject invoking - gọi đến một Subject khác : Khi một Process gửi request đến Procedure để thực hiện một số loại tác vụ [task]. Subjects chỉ được phép gọi đến các công cụ ở Lower Integrity Level. Với quy tắc Invocation Property, hệ thống đảm bảo Dirty Subject sẽ không thể nào gọi đến Clean Tool để làm Contamine - Ô Nhiễm một Clean Object.

Bell-LaPadula vs Biba

Bell-LaPadula Model được sử dụng để cung cấp Confidentiality - Tính Bảo Mật. Biba Model được sử dụng để cung cấp Integrity - Tính Toàn Vẹn. Bell-LaPadula và Biba Models là những Information Flow Models, bởi vì điều chúng quan tâm nhất chính là Data Flowing - Dòng chảy Dữ Liệu từ 1 Level này đến 1 Level khác. Bell-LaPadula sử dụng Security Levels và Biba sử dụng Integrity Levels.

Điều quan trọng là người dự CISSP phải nắm vững các quy tắc của Biba và Bell-LaPadula. Những quy tắc này nghe có vẻ rất giống nhau : Simple và *[star] Rules.

Tuy nhiên cách Read và Write của các quy tắc này thật sự khác nhau. Một mẹo để chúng ta có thể ghi nhớ đó là nếu từ "Simple" được sử dụng, có nghĩa quy tắc đó đang nói về Reading. Nếu quy tắc sử dụng dấu hiệu * hoặc "Star", có nghĩa nó đang nói về Writing. Cho nên, chúng ta chỉ cần nhớ về cách Reading và Writing của mỗi Model mà thôi.

The Clark-Wilson Model

Clark-Wilson Model được phát triển sau Biba, có một số cách tiếp cận khác so với Biba trong việc bảo vệ Integrity của thông tin. Model này sử dụng những yếu tố sau :

• Users : Active agents - Các tác nhân hoạt động • Transformation procedures [TPs] : Các hoạt động trừu tượng đã được lập trình, chẳng hạn như Read, Write và Modify • Constrained data items [CDIs] : Chỉ có thể được thao tác - manipulated bởi TPs • Unconstrained data items [UDIs] : Có thể được thao tác bởi Users thông qua các hoạt động Read và Write nguyên thủy [primitive] • Integrity verification procedures [IVPs] : Kiểm tra Consistency - Tính Nhất Quán của CDIs với External Reality - Tính Chính Xác Bên Ngoài

Mặc dù danh sách này trong có vẻ khá áp đảo, nhưng thật sự nó rất đơn giản. Khi Application sử dụng Clark-Wilson Model, nó sẽ phân tách Data vào trong một Subset - Tập hợp con có nhu cầu được bảo vệ cao [highly protected], nó gọi là Constrained Data Item [CDI], và một Subset khác không đòi hỏi sự bảo vệ cao [none highly protected], nó gọi là Unconstrained Data Item - [UDI].

Users không được phép modify - sửa đổi Critical Data [CDI] một cách trực tiếp. Thay vào đó, Subject [user] bắt buộc phải được authenticated với một phần của Software, và Software Procedures [TPs] sẽ thực hiện các hoạt động này thay cho User.

Ví dụ, khi cô Năm Bánh Ú cần cập nhật thông tin nằm bên trong Database của công ty cô ta, cô ấy sẽ không được phép thực hiện điều đó mà không có một phần Software kiểm soát các hoạt động này. Trước tiên, cô Năm bắt buộc phải authenticate - xác thực với chương trình, có vai trò như một Front End dành cho Database, sau đó chương trình sẽ kiểm soát những gì cô Năm Bánh Ú có thể và không thể làm đối với thông tin trong Database. Điều này thường được gọi là Access Triple - Bộ 3 Truy Cập : Subject [user], Program [TP], Object [CDI]. User không thể sửa đổi CDI mà không cần sử dụng TP.

Cô Năm Bánh Ú sẽ đưa vào một số Input Data, giả định rằng điều này sẽ overwrite - ghi đè lên một số Original Data trong Database. Software [TP] đảm bảo rằng loại hoạt động này Secure và sẽ thực hiện Write Procedures - Thủ Tục Ghi cho cô Năm Bánh Ú. Cô Năm và bất kỳ loại Subject nào cũng đều không đáng tin cậy đủ để thao tác trực tiếp đến các Objects.

Integrity của CDI bắt buộc phải được bảo vệ bởi các TPs. UDI không đòi hỏi mức độ bảo vệ cao. Ví dụ, nếu cô Năm Bánh Ú thực hiện việc thay đổi thông tin trong Banking Online của cô ta, Data trên Servers và Databases của ngân hàng sẽ được tách ra thành 2 loại là UDI và CDI. Loại CDI sẽ chứa thông tin tài khoản ngân hàng của cô Năm, cần được bảo vệ cao. Loại UDI có thể là thông tin cá nhân của cô Năm [số điện thoại, địa chỉ nhà, giới tính..] mà cô ta có thể cập nhật khi cần thiết. Transformation Procedures - TPs sẽ không cần thiết khi cô Năm cần cập nhật thông tin UDI của cô ta.

Trong một số trường hợp, hệ thống có thể cần thay đổi UDI Data thành CDI Data. Ví dụ, khi cô Năm cập nhật thông tin cá nhân của mình thông qua Website để hiển thị đúng địa chỉ nhà mới của cô ta, thông tin này sẽ cần được di chuyển vào trong Banking Software, chịu trách nhiệm gửi thư thông tin tài khoản ngân hàng. Ngân hàng không muốn cô Năm tương tác trực tiếp với Banking Software, vì vậy một phần của Software sẽ chịu trách nhiệm trong việc copy - sao chép Data và cập nhật địa chỉ gửi thư này của khách hàng. Trong giai đoạn này, TP sẽ thay đổi State - Trạng thái của UDI Data thành CDI. Những khái niệm này được thể hiện trong Figure 5-17.

Hãy nhớ rằng đây là Integrity Model - Mô Hình Tính Toàn Vẹn, cho nên nó phải có một cái gì đó đảm bảo rằng những quy tắc toàn vẹn cụ thể [specific integrity rules] đang được thực hiện. Đây là công việc của IVP. IVP đảm bảo rằng tất cả Critical Data [CDI] đều phải tuân thủ theo những quy tắc toàn vẹn đã xác định của Application. Thông thường tâm lý của người mới học về các Models sẽ tập trung vào việc đánh cờ caro ! Bởi vì những Models này thật sự rất lý thuyết và khá trừu tượng.

Do đó, khi họ đặt ra câu hỏi phổ biến : Những quy tắc toàn vẹn nào mà CDI bắt buộc phải tuân thủ ? Họ sẽ nhận được câu trả lời : Bất cứ điều gì nhà cung cấp lựa chọn cho họ.

Model được tạo nên từ constructs - các cấu trúc, mathematical formulas - các công thức toán học và một vài tiến sĩ PhD. Model cung cấp Framework mà có thể được sử dụng để tích hợp một đặc tính nào đó vào bên trong Software [confidentiality, integrity, và vân vân]. Cho nên Model không đặt ra những Integrity Rules nào mà IVP bắt buộc phải thực thi; Model chỉ cung cấp Framework, và Vendors mới chính là người chọn lựa Integrity Rules. Vendor triển khai thực hiện những Integrity Rules dựa trên điều mà khách hàng của họ cần nhất.

Cho nên nếu Vendor đang phát triển Application cho một tổ chức tài chính, UDI có thể là Customer Profiles - Hồ Sơ Khách Hàng mà cho phép họ tự động cập nhật và CDI có thể là Bank Account Information - Thông Tin Tài Khoản Ngân hàng, thường được lưu trữ trong các hệ thống Mainframe. UDI Data không cần phải được bảo vệ cao và có thể được đặt trên cùng một hệ thống hoặc ở một hệ thống khác. User có thể truy cập vào UDI Data mà không cần sử dụng TP, nhưng khi User cần truy cập đến CDI, họ bắt buộc phải dùng TP.

Cho nên Vendor, người phát triển sản phẩm sẽ là người xác định loại Data nào được xem là UDI và loại Data nào được xem là CDI, cũng như sẽ phát triển TPs để control - kiểm soát và bố trí xem làm thế nào Software thực thi Integrity của các giá trị CDI.

Trong Banking Application, IVP sẽ đảm bảo rằng CDI đại diện cho Correct Value - Giá Trị Chính Xác. Ví dụ, nếu cô Năm có 20 triệu trong tài khoản của mình và gửi thêm 5 triệu, CDI đối với tài khoản của cô ta lúc này nên có giá trị là 25 triệu. IVP đảm bảo Consistency - Tính nhất quán của dữ liệu. Vì vậy sau khi cô Năm thực hiện giao dịch này và IVP xác minh [validates] tính toàn vẹn của CDI [giá trị tài khoản ngân hàng "new" là chính xác], khi đó CDI sẽ được coi là một Consistent State - Trạng Thái Nhất Quán.

TPs là những thành phần duy nhất được phép thay đổi State của CDIs. Trong ví dụ của chúng ta, TPs sẽ là Software Procedures thực hiện những tác vụ chuyển tiền, rút tiền, gửi tiền. Sử dụng TPs để thay đổi CDIs thường được gọi là Well-formed Transaction.

Well-formed Transaction là một loạt các hoạt động được thực hiện để Transfer - Vận chuyển Data từ một Consistent State này đến một Consistent State khác. Nếu cô Năm chuyển tiền từ tài khoản doanh nghiệp của cô ấy đến tài khoản tiết kiệm của cô ấy, Transaction này được thực hiện bởi 2 hoạt động : Trừ tiền từ một tài khoản và thêm nó vào một tài khoản khác. Bằng cách đảm bảo giá trị mới trong tài khoản doanh nghiệp và tài khoản tiết kiệm của cô ta là chính xác và tính toàn vẹn của chúng còn nguyên vẹn, IVP sẽ maintain - duy trì Internal và External Consistency.

Clark-Wilson Model cũng đưa ra cách làm thế nào để tích hợp Separation of Duties vào trong kiến trúc của Application. Ta lại lấy ví dụ về Banking Software, nếu khách hàng cần rút hơn 1 tỷ, Application có thể yêu cầu giám sát viên đăng nhập và xác thực giao dịch này. Đây là một biện pháp đối phó [countermeasure] với các hoạt động gian lận tiềm ẩn. Model này cung cấp các quy tắc mà nhà phát triển bắt buộc phải tuân theo để triển khai và thực thi đúng cách Separation of Duties thông qua Software Procedures.

Goals of Integrity Models - Mục tiêu của các Mô Hình Tính Toàn Vẹn

Sau đây là 3 mục tiêu chính của các Integrity Models :

• Ngăn chặn người dùng trái phép tạo ra những sự sửa đổi - modifications. • Ngăn chặn người dùng hợp pháp tạo ra những sự sửa đổi không phù hợp - improper modifcations [separation of duties]. • Duy trì Internal và External Consistency [well-formed transaction]

Clark-Wilson giải quyết những mục tiêu này trong Model của nó. Biba chỉ giải quyết mục tiêu đầu tiên.

Internal và External Consistency được cung cấp bởi IVP - Integrity Verification Procedures, đảm bảo rằng những gì được lưu trữ trong hệ thống như CDI được ánh xá đúng với giá trị đầu vào - input value mà modified State của nó. Cho nên nếu cô Năm có 20 triệu trong tài khoản và rút ra 2 triệu, kết quả trong CDI là 18 triệu.

Tóm lại, Clark-Wilson Model thực thi 3 mục tiêu của Integrity bằng cách sử dụng Access Triple [subject, software [TP], object], separation of duties và auditing. Model này thực thi Integrity bằng cách sử dụng Well-formed transactions [thông qua Access Triple] và Separation of user Duties - Phân tách nhiệm vụ của người dùng.

The Information Flow Model

Bell-LaPadula Model tập trung vào việc ngăn chặn thông tin chảy từ High Security Level đến Low Security Level. Biba Model tập trung vào việc ngăn chặn thông tin chảy từ Low Integrity Level đến High Integrity Level. Cả hai Models này đều được xây dựng dựa trên Information Flow Model. Information Flow Models có thể giải quyết bất kỳ loại Information Flow - Dòng Chảy Thông Tin, không chỉ từ một Security [hoặc Integrity] Level này đến một Level khác.

Trong Information Flow Model, Data được lưu trữ trong các compartments - ngăn rời rạc và riêng lẻ. Trong Bell-LaPadula Model, những compartments này là dựa trên Security Levels. Hãy nhớ rằng MAC system [đã học trong Domain Access Control] là dựa trên Bell-LaPadula Model. Mac systems sử dụng Labels trên từng Subject và Object. Label của Subject chỉ ra cho biết Clearance của Subject và Need to Know. Label của Object chỉ ra Classification và Categories của Object.

Nếu bạn đang ở trong quân đội và có Top-secret Clearance, điều này không có nghĩa bạn được quyền truy cập vào tất cả thông tin Top-secret. Thông tin được ngăn cách [compartmentalized] dựa trên 2 yếu tố : Classification và Need to Know. Clearance của bạn dominate [cao hơn hoặc bằng] Classification của Object và Security Profile của bạn bắt buộc phải chứa một trong các Categories được liệt kê trong Label của Object, điều đó sẽ thực thi khái niệm Need to Know.

Cho nên Bell-LaPadula là một Information Flow Model, đảm bảo rằng thông tin không thể "chảy" từ một ngăn này đến một ngăn khác theo cách thức có thể đe dọa đến Confidentiality của Data. Biba ngăn cách Data dựa trên Integrity Levels. Nó là một Information Flow Model, kiểm soát Information Low nhằm để đảm bảo Integrity của các thông tin đáng tin cậy nhất.

Information Flow - Dòng chảy thông tin nằm bên trong hệ thống như thế nào ? Câu trả lời là có nhiều cách. Subject có thể access files. Processes có thể access memory segments. Khi Data được di chuyển từ Swap Space của ổ cứng vào trong Memory, chúng chính là Information Flows. Data được di chuyển vào và ra khỏi Registers trên CPU. Data được chuyển vào các thiết bị lưu trữ Cache Memory khác nhau. Data được ghi vào ổ cứng, CD-Rom, vân vân. Kiểm soát chính xác tất cả những cách Information Flows này có thể là một nhiệm vụ vô cùng phức tạp.

Đây là lý do tại sao Information Flow Model tồn tại, để giúp cho các nhà phát triển đảm bảo Software của họ không cho phép thông tin "flow" theo cách mà có thể đặt hệ thống hoặc Data vào trong nguy hiểm. Có một cách mà Information Flow Model cung cấp là loại bảo vệ đảm bảo các Covert Channels không tồn tại trong Code.

Covert Channels

Covert Channel - Kênh Bí Mật là cách một thực thể [entity] nhận được thông tin theo một cách trái phép. Nó là Information Flow mà không được kiểm soát [not controlled] bởi các cơ chế an ninh. Đây là loại Information Path không được phát triển cho việc liên lạc [communication]; Do đó, hệ thống sẽ không bảo vệ đúng cách con đường [path] này, bởi vì các nhà phát triển không bao giờ hình dung ra được thông tin được truyền tải qua con đường này. Tiếp nhận thông tin theo cách này rõ ràng là vi phạm vào chính sách bảo mật của hệ thống.

Channel này truyền tải dữ liệu một cách trái phép là hệ quả của một trong những hoàn cảnh sau đây :

• Improper Oversight - Giám sát không đúng cách trong việc phát triển sản phẩm. • Improper Implementation - Triển khai thực hiện Access Controls không đúng cách bên trong Software. • Existence - Sự tồn tại của Shared Resource giữa hai thực thể.

Covert Channel có 2 loại : Storage và Timing.

Trong Covert Storage Channel, các Processes có thể communicate thông qua một số loại Storage Space trên hệ thống. Ví dụ, System A nhiễm một con Trojan, con này đã cài đặt một Software mà có thể communication đến Process khác trong một cách hạn chế. System A có 1 file rất nhạy cảm [File 2] mà kẻ tấn công cực kỳ quan tâm đến file này. Software mà con Trojan đã cài đặt có thể Read file này và nó cần gửi nội dung của file này đến cho kẻ tấn công, nhưng chỉ có thể gửi một 1 Bit tại một thời điểm.

Software này sẽ communicate đến kẻ tấn công bằng cách Locking một File cụ thể [File 3]. Khi kẻ tấn truy cập đến File 3 và thấy nó đã bị Software locked, kẻ tấn công sẽ hiểu rằng First Bit - Bit đầu tiên trong file nhạy cảm mà hắn quan tâm chính là 1. Lần thứ hai, kẻ tấn công truy cập đến File 3 và thấy nó không còn bị Locked nữa. Kẻ tấn công sẽ ngầm hiểu giá trị kế tiếp là Bit 0. Điền này sẽ liên tục diễn ra cho đến khi toàn bộ Bit của file nhạy cảm được gửi đến kẻ tấn công, vậy là hắn ta đã đạt được mục đích đánh cắp nội dung file nhạy cảm thông qua việc thu thập Bit của file nhạy cảm.

Trong ví dụ trên, Trojan software thể hiện một vai trò như Messenger - Người Đưa Tin. Nó có thể truy cập đến dữ liệu nhạy cảm và sử dụng một File khác trên ổ cứng để gửi tín hiệu đến cho kẻ tấn công.

Còn một cách khác để tấn công Covert Storage Channel có thể diễn ra, đó là thông qua File Creation - Tạo Tập Tin. Một hệ thống đã bị xâm nhập, đã bị cài Trojan Software mà có thể Create và Delete Files bên trong một thư mục cụ thể và đã có thể Read Access đến File nhạy cảm. Khi Trojan Software thấy First Bit của dữ liệu bên trong file nhạy cảm là 1, nó sẽ Tạo ra một file có tên là Temp trong một thư mục cụ thể. Kẻ tấn sẽ cố gắng Create [hoặc upload] một File trùng tên với file mà Trojan Software đã tạo, khi đó kẻ tấn công sẽ nhận được một thông báo lỗi : Trùng tên File !

Lúc bấy giờ, kẻ tấn công sẽ biết được rằng Bit đầu tiên trong file nhạy cảm là 1. Kẻ tấn công sẽ cố gắng thử Create lại File này một lần nữa, khi hệ thống cho phép điều này diễn ra, nghĩa là Trojan Software trên hệ thống đã Deleted file mà nó đã tạo ra, có nghĩa Bit thứ 2 là 0.

Information Flow Models tạo ra các quy tắc [rules] để đảm bảo Covert Channels không tồn tại. Có rất nhiều cách Information Flows bên trong một hệ thống, để xác định và diệt trừ [rooting] các Covert Channels thường một việc vô cùng khó khăn hơn những gì người ta nghĩ lúc ban đầu.

Trong kỹ thuật tấn công Covert Timing Channel, Process sẽ relay - chuyển tiếp thông tin đến một Process khác bằng cách sử dụng Modulating - Điều biến tài nguyên hệ thống. 2 Processes communicating với nhau bằng cách sử dụng cùng một Shared Resource, đó là Time - Thời Gian.

Trong ví dụ của chúng ta, Process A là một phần của Software bất chính đã được cài đặt vào hệ thống thông qua Trojan. Trong hệ thống Multitasked, mỗi Process được cung cấp chức năng truy cập để tương tác với CPU. Khi chức năng này được cung cấp cho Process A, nó sẽ từ chối chức năng này - điều này chỉ ra giá trị 1 cho kẻ tấn công biết. Lần tiếp theo Process A được cung cấp chức năng truy cập, nó sẽ sử dụng chức năng này - điều này chỉ ra giá trị 0 cho kẻ tấn công biết. Kỹ thuật tấn công này như một loại mã Morse, nhưng sử dụng một số loại tài nguyên hệ thống để làm tín hiệu.

Covert Channel Countermeasure

Bởi vì tất cả các HĐH đều có một số loại Covert Channel, cho nên không khả thi cho lắm khi muốn loại bỏ tất cả bọn chúng ra khỏi chúng ta. Số lượng Covert Channel được chấp nhận thường phụ thuộc vào Assurance Rating của hệ thống. Một hệ thống đạt EAL 6 Rating sẽ có ít Covert Channels hơn so với hệ thống có EAL rating 3, bởi vì EAL 6 Rating đại diện cho hệ thống có mức độ đảm bảo cung cấp sự bảo vệ cao hơn so với hệ thống có EAL 3 Rating. Không có nhiều người dùng có thể chống lại những Channels này; Do đó, Channels bắt buộc phải được giải quyết khi hệ thống được xây dựng và phát triển.

Chú ý : Trong Orange Book, Covert Channels trong các HĐH không được đề cập đến, cho đến Security Level B2 và các mức độ từ B2 trở lên. Bởi vì những hệ thống này có tính bảo mật rất cao, nắm giữ những dữ liệu vô cùng nhạy cả,m tất cả những người muốn truy cập đến loại dữ liệu nhạy cảm này đều phải đi qua rất nhiều bước "rắc rối cần thiết" mới có thể chạm đến được dữ liệu.

The Noninterference Model

Multilevel Security Properties - Đặc Tính Bảo Mật Đa Lớp có thể được diễn tả bằng nhiều cách, một trong số đó là cách Non-Interference - Không Va Chạm Nhau. Khái niệm này được thực hiện để đảm bảo bất kỳ hành động nào diễn ra tại Higher Security Level, cũng không gây ảnh hưởng hoặc va chạm đến các hành động diễn ra tại Lower Security Level.

Đây là loại Model không quan tâm bản thân nó với dòng chảy của dữ liệu. Cho nên nếu có một thực thể nào đó ở Higher Security Level thực hiện một hành động, nó sẽ không làm thay đổi State của một thực thể nào khác tại Lower Level. Nếu thực thể ở Lower Level nhận thức được hoạt động nào đó đã diễn ra bởi thực thể ở Higher Level và trạng thái của hệ thống đã thay đổi đối với thực thể ở Lower-Level này, thực thể có thể sẽ suy ra được quá nhiều thông tin về các hoạt động của Higher State, điều đó có thể mang lại sự rò rỉ thông tin.

Người dùng ở Lower Security Level không cần phải biết các commands được thực thi bởi người dùng ở Higher Security Level và không bị ảnh hưởng bởi các commands này trong bất kỳ cách nào.

Chúng ta giả sử rằng Tom và Jerry cả hai cùng làm việc trên một hệ thống Multilevel Mainframe cùng một lúc. Tom có Security Clearance là Secret và Jerry có Security Clearance là Top Secret. Vì đây là một Central Mainframe, terminal của Tom đang hoạt động trong bối cảnh Secret, và Jerry đang làm việc trên chính terminal của cô ta, hoạt động trong bối cảnh Top Secret.

Model này tuyên bố rằng Jerry không được làm ảnh hưởng dù trực tiếp hay gián tiếp đến Domain [available resources & working environment] của Tom. Cho nên bất kỳ Commands nào mà Jerry thực thi hoặc bất kỳ Resources nào mà Jerry tương tác cũng không gây ảnh hưởng gì đến công việc mà Tom đang làm trong Mainframe cả. Điều này nghe có vẻ đơn giản, cho đến khi chúng ta thực sự hiểu Model này đang muốn nói gì.

Có vẻ như rất đơn giản và dễ hiểu khi Jerry thực thi command mà không gây ảnh hưởng đến terminal của Tom. Đúng nhưng chưa đủ, mục đích thực sự của Model này chính là để giải quyết Covert Channels và Inference Attacks - Những cuộc tấn công suy diễn. Model này quan sát các Resources đã được chia sẻ, mà các Users khác nhau của hệ thống sẽ sử dụng và cố gắng xác định làm thế nào thông tin có thể được truyền qua từ một Process đang hoạt động ở Higher Security Clearance đến một Process đang hoạt động ở Lower Security Clearance.

Từ khi Tom và Jerry làm việc trên cùng một hệ thống tại cùng một thời điểm, họ rất có thể sẽ phải chia sẻ cùng một Resource với nhau. Cho nên Model này tạo ra các quy tắc để đảm bảo Jerry sẽ không thể nào truyền tải dữ liệu đến Tom thông qua Covert Storage Channels hoặc Covert Timing Channels.

Một loại vi phạm an ninh khác mà Model này sẽ giải quyết đó chính là Inference Attack. Inference Attack xảy ra khi một người nào đó truy cập đến một số loại thông tin và có thể Infer - Suy diễn [hoặc guess - đoán] ra một điều gì đó mà anh ta không có Clearance Level hoặc Authority để biết nó.

Ví dụ, giả sử Tom đang làm việc với một File chứa thông tin về các nguồn dự trữ [supplies] đang được gửi sang Russia. Tom đóng file này lại và 1 giờ sau lại mở File này lên. Trong thời gian này, Classification của anh ta đã được nâng lên thành Top Secret, cho nên khi Tom cố gắng truy cập đến file này, anh ta bị từ chối. Tom có thể infer [suy luận] ra rằng một số loại nhiệm vụ Top-Secret đang chuẩn bị sẵn sàng diễn ra với đất nước Russia.

Anh ta không có Clearance để biết điều này, do đó nó sẽ là một cuộc tấn công Inference Attack hoặc Leaking Information. Inference Attack sẽ được đề cập chi tiết trong Domain : Application Security.

The Lattice Model

Lattice là một cấu trúc toán học được xây dựng dựa trên khái niệm một nhóm, một tập thể. Định nghĩa phổ biến nhất của Lattice Model chỉ có thể được hiểu bởi những người ngay từ đầu đã biết về nó. Công nhận vô lý quá nhỉ !? Điều này cũng tương tự như định nghĩa của Metadata - Siêu dữ liệu : "Data của Data". Chỉ sau khi chúng ta thực sự hiểu Metadata là gì thì định nghĩa của nó mới có "cảm giác" với chúng ta, hết sức nghịch lý. Cho nên định nghĩa của Lattice Model cũng không hữu ích cho lắm.

Lattice với lời giải thích toán học có thể là tác phẩm của những người ngoài hành tinh, chỉ có những người đạt được Master hoặc bằng PhD toán học mới hy vọng có thể hiểu được chút chút. Model này cần phải được giải thích bởi "ngôn ngữ quần chúng" để cho ai cũng có thể hiểu được nó. Vậy chúng ta thử xem sao nhé.

MAC Model đã được giải thích trong Domain : Access Control, được xây dựng dựa trên chương này. Trong Model này, Subjects và Objects đều có Labels. Mỗi Label của Subject đều có chứa Clearance và Need-to-know categories mà Subject này có thể truy cập.

Giả sử Clearance của Kathy là Top Secret và cô ta chính thức được cho phép truy cập vào các loại thông tin có tên gọi là Iraq và Korea, dựa trên Need-to-know của cô ta. Cho nên Label của Kathy sẽ nêu rõ các thứ sau đây : Top Secret {Irad, Korea}. Table 5-1 cho thấy các Files khác nhau trên hệ thống trong kịch bản này. Hệ thống được xây dựng dựa trên MAC Model, có nghĩa là HĐH sẽ đưa ra quyết định truy cập dựa vào nội dung của Security Label.

Kathy cố gắng truy cập vào File B vì Clearance của cô ta lớn hơn so với Classification của File B, cho nên cô ta có thể Read file này nhưng không thể Write nó. Đây là nơi "partially ordered set together with least upper and greatest lower bound operators on the set” bước vào cuộc chơi. Set là Subject [Kathy] và Object [file]. Nó là một Partially Ordered Set bởi vì tất cả các Access Controls đều không hoàn toàn bằng nhau [equal].

Hệ thống phải quyết định giữa Read, Write, Full Control, Modify và các loại Access Permission khác được sử dụng trong HĐH này. Cho nên, "partially ordered" có nghĩa là hệ thống "Đã áp dụng hầu hết" các Access Controls đối với Set này. "Least Upper Bound" có nghĩa là hệ thống nhìn vào tuyên bố của Access Control [Kathy có thể Read file] và một tuyên bố khác [Kathy không thể Write file] và đưa ra giá trị Least Upper Bound. Vì "no write" hạn chế hơn so với Read. Cho nên Least Upper Bound của Kathy truy cập đến file này là Read và Greates Lower Bound là No Write.

Figure 5-18 minh họa các Bounds - Giới hạn của việc truy cập. Đây là một cách nói hơi khó hiểu : "Điều lớn nhất Kathy có thể làm với File B này là Read nó. Điều nhỏ nhất Kathy có thể làm là No Write nó".

Chúng ta hãy thử tìm hiểu về Least Upper Bound và Greatest Lower Bound Access Levels đối với Kathy và File C. Clearance của Kathy equal - bằng với Classification của File C. Theo Bell-LaPadula Model, điều này khớp với Strong Star Property. [Hãy nhớ Strong Star Property tuyên bố rằng: Một Subject có thể Read và Write đến một Object có cùng một Security Level]. Cho nên Least Upper Bound là Write và Greatest Lower Bound là Read.

Nếu chúng ta nhìn vào Security Label của File D, chúng ta sẽ thấy nó có category mà Kathy không có trong Security Label của cô ta, đó là Iran. Điều này có nghĩa Kathy "không có nhu cầu - don't need to know" có quyền truy cập đến File này. Cả Least Upper Bound và Greatest Lower Bound đều sẽ là No Access.

Đây là một Formal Model - Mô Hình Chính Thức, có nghĩa nó có thể được chứng minh toán học trong việc cung cấp một mức độ bảo vệ cụ thể nếu tất cả các quy tắc của nó đều được tuân thủ đúng cách. Tìm hiểu về những Models này giống như ta đang tìm hiểu về những điều cơ bản của bộ môn Hóa Học. Trong cuốn sách này, chúng ta chỉ đang tìm hiểu về những thành phần cơ bản nhất của các Models mà thôi...

The Brewer and Nash Model

a.k.a Chinse Wall Model

Brewer and Nash Model, còn được gọi là Chinse Wall Model. Nó được tạo ra để cung cấp các Access Controls mà có thể change dynamically - tự động thay đổi tùy thuộc vào hành động trước đó của người dùng. Mục đích chính của Model này là để bảo vệ chống lại những xung đột lợi ích [conflicts of interest] bởi sự truy cập của các Users.

Ví dụ, nếu một công ty Marketing cung cấp chương trình khuyến mãi tiếp thị cho 2 ngân hàng, nhân viên đang làm việc trong dự án của Ngân Hàng A không nên "xem" thông tin về chương trình tiếp thị của Ngân Hàng B. Hành động này có thể tạo ra sự xung đột lợi ích, bởi vì các ngân hàng là đối thủ cạnh tranh của nhau. Nếu Project Manager [thuộc công ty marketing] của project Ngân Hàng A có thể xem thông tin về chiến dịch marketing của Ngân Hàng B, anh ta có thể dùng nó làm con ách chủ bài để làm hài lòng khách hàng của anh ta, chính là Ngân Hàng A.

Công ty Marketing sẽ phải đón nhận danh tiếng vô cùng xấu nếu như cho phép các nhân viên của mình hành xử một cách vô trách nhiệm. Cho nên công ty Marketing có thể triển khai thực hiện một sản phẩm để Track - Theo dõi các hoạt động truy cập của Project Manager và không cho phép các yêu cầu truy cập mà có thể gây ra sự xung đột lợi ích.

Trong Figure 5-19, Chúng ta thấy rằng khi người đại diện [Project Manager] truy cập đến thông tin của Ngân Hàng A, hệ thống sẽ automatically - tự động tạo Off Limits [giới hạn] thông tin của Ngân Hàng B. Ngược lại khi người đại diện ĐÃ truy cập thông tin của Ngân Hàng B, thì thông tin của Ngân Hàng A sẽ tự động Off Limits.. Những cơ chế Access Controls này có thể thay đổi tự động tùy thuộc vào hành vi, authorization và các requests trước đó của Users.

Chinese Wall Model cũng dựa trên Information Flow Model. Không Information nào có thể "flow" giữa Subjects và Objects mà có khả năng đem lại kết quả xung đột lợi ích. Model này tuyên bố rằng Subject có thể Write đến một Object khi và chỉ khi Subject không thể Read các Objects khác nằm bên trong Dataset khác. Cho nên trong ví dụ của chúng ta, Project Manager sẽ không thể Write đến bất kỳ Objects nào nằm trong Dataset của Ngân hàng A, NẾU anh ta đã có khả năng Read mọi Objects trong Dataset của Ngân Hàng B.

Đây chỉ là một ví dụ về cách mà Model này có thể được sử dụng. Các ngành công nghiệp khác nhau sẽ có những xung đột lợi ích khác nhau.

The Graham-Denning Model

Hãy nhớ rằng đây đều là những Models, cho nên chúng không phải là một cái gì đó cụ thể trong tự nhiên. Mỗi một Vendor cần phải quyết định cách đáp ứng các quy tắc mà họ đã vạch ra trong Model đã được chọn. Bell-LaPadula và Biba không định nghĩa cách làm thế nào Security Rating và Integrity Rating được xác định và được sửa đổi, cũng không cung cấp cách Delegate - Ủy Thác hay chuyển giao Access Rights.

Graham-Denning Model sẽ giải quyết những vấn đề đó và xác định một Set of Basic Rights - Tập hợp các quyền hạn cơ bản trong các Commands mà một Subject có thể thực thi đến một Object. Model này có 8 Primitive Protection Rights - Quyền hạn Bảo Vệ "Gốc", hoặc các quy tắc trong việc làm thế nào các chức năng có thể diễn ra an toàn :

• Làm thế nào để Create - Tạo ra Object một cách an toàn [securely]. • Làm thế nào để Create - Tạo ra Subject một cách an toàn. • Làm thế nào để Delete - Xóa Object một cách an toàn. • Làm thế nào để Delete - Xóa Subject một cách an toàn. • Làm thế nào để cung cấp Read Access Right một cách an toàn. • Làm thế nào để cung cấp Grant Access Right một cách an toàn. • Làm thế nào để cung cấp Delete Access Right một cách an toàn. • Làm thế nào để cung cấp Transfer Access rights một cách an toàn.

Những điều này nghe có vẻ không đáng kể, nhưng khi bạn đang xây dựng một hệ thống an toàn, chúng là những điều vô cùng quan trọng.

The Harrison-Ruzzo-Ullman Model

Harrison-Ruzzo-Ullman [HRU] Models giải quyết về vấn đề Access Rights của Subjects và Integrity của những Rights này. Subject chỉ có thể thực hiện một số Operations có giới hạn đối với một Object. Từ khi Security trở nên "đơn giản", thật dễ dàng đối với một hệ thống để Allow hoặc Disallow authorization of Operations nếu 1 Command bị giới hạn đến một Single Operation.

Ví dụ, nếu Subject gửi command X, chỉ yêu cầu operation Y, điều này thật đơn giản để hệ thống Allow hoặc Disallow Operation này diễn ra. Tuy nhiên, nếu Subject gửi command M và hoàn thành command này, các operations N, B, W và P đã được thực hiện, khi đó có rất nhiều sự phức tạp đối với hệ thống trong việc ra quyết định, nếu command này đã được authorized.

Security Modes of Operation

Hệ thống có thể vận Hành trong các Modes - Chế Độ khác nhau tùy thuộc vào mức độ nhạy cảm của dữ liệu mà nó xử lý, mức độ Clearance của Users và những Users nào được authorized để làm một điều gì đó. Mode of Operation - Chế độ hoạt động mô tả các Security Conditions - Điều Kiện An Ninh mà theo đó hệ thống sẽ có những Functions cần thiết.

Những Modes này được sử dụng trong hệ thống MAC [Mandatory-access-control], nắm giữ một hoặc nhiều Classifications của dữ liệu. Một số điều sau đây cần phải xem xét khi xác định Mode cho hệ thống :

• Loại Users, những người sẽ trực tiếp hoặc gián tiếp kết nối đến hệ thống. • Loại Data [classification levels và categories] sẽ được xử lý trên hệ thống. • Clearance Levels, need to know và Formal Access Approvals mà người dùng sẽ có.

Những phần sau đây sẽ mô tả các Security Modes khác nhau mà hệ thống có thể được phát triển và cấu hình để làm việc bên trong chúng.

Dedicated Security Mode

Một hệ thống được xem là đang vận hành trong Dedicated Security Mode, khi tất cả người dùng đều có Clearance và Need to Know cần thiết đối với tất cả [all] Data được xử lý bên trong hệ thống. Tất cả người dùng đều đã được phê duyệt [approval] Formal Access đối với tất cả thông tin trên hệ thống và đã ký NDA liên quan đến thông tin này. Hệ thống có thể xử lý Single Classification Level của thông tin.

Nhiều hệ thống quân sự được thiết kế chỉ để xử lý 1 Security Level duy nhất, hoạt động trong Dedicated Security Mode. Điều này đòi hỏi tất cả những người sử dụng hệ thống đều phải có Highest Clearance Level được yêu cầu bởi tất cả Data trong hệ thống. Nếu hệ thống đang nắm giữ Top-Secret Data thì chỉ có những người dùng sở hữu Clearance tương đương Top-Secret mới có thể sử dụng hệ thống.

Các hệ thống quân sự khác hoạt động với Multiple Security Levels, điều đó được thực hiện bằng cách compartment - ngăn Data. Những hệ thống này có thể hỗ trợ người dùng sở hữu đồng thời High và Low Clearances Level.

System High-Security Mode

Một hệ thống được xem là đang vận hành trong System High-Security Mode, khi tất cả người dùng đều có Clearance để truy cập đến thông tin, nhưng không nhất thiết phải có Need To Know đối với tất cả thông tin được xử lý trên hệ thống. Vì vậy, không giống như Dedicated Security Mode, trong đó tất cả người dùng đều phải có Need-to-know liên quan đến tất cả [all] dữ liệu trong hệ thống. Trong System High-Security Mode, tất cả người dùng chỉ cần có Need-to-know liên quan đến một số Data cụ thể mà thôi [không đòi liên quan đến all].

System High-Security Mode cũng yêu cầu người dùng phải có Highest Level of Clearance dành cho mọi dữ liệu trong hệ thống. Tuy nhiên, ngay cả khi người dùng đã có Security Level cần thiết để truy cập đến một Object, thì người dùng vẫn có thể bị Restricted - Hạn chế, nếu như họ không có một Need-to-know liên quan đến Object cụ thể đó.

Compartmented Security Mode

Một hệ thống được xem là đang vận hành trong Compartmented Security Mode, khi tất cả mọi người dùng đều có Clearance để truy cập đến mọi thông tin được xử lý bởi hệ thống trong System High-Security Configuration, nhưng có thể không có Need-to-know và Formal Access Approval.

Điều này có nghĩa là nếu một hệ thống đang nắm giữ Secret và Top-Secret Data, thì tất cả người dùng đều bắt buộc phải có ít nhất [at least] là Top-Secret Clearance để truy cập đến hệ thống này. Đây là sự khác biệt của Compertmented Mode và Multilevel Security Modes. Cả 2 Modes đều yêu cầu người dùng phải có Need-to-know hợp lệ [valid], NDA và Formal Approval.

Nhưng Compartmented Security Mode đòi hỏi người dùng phải có Clearance dominates [cao hơn hoặc bằng] với mọi Data trong hệ thống, trong khi Multilevel Security Mode chỉ đòi hỏi người dùng phải có Clearance để truy cập đến Data mà anh ta sẽ làm việc với nó.

Trong Compartmented Security Mode, người dùng bị hạn chế việc truy cập đến một số thông tin bởi vì họ không cần phải truy cập nó để thực hiện những Functions trong công việc của họ và họ không được trao cho Formal Approval để truy cập nó. Điều này sẽ được thực thi [enforced] bởi tất cả các Objects Security Labels, phản ánh mức độ nhạy cảm của thông tin [classification level, classification category, handling procedures]. Trong Mode này, người dùng chỉ có thể truy cập vào một compartment của dữ liệu, được thực thi bởi Mandatory Access Controls.

Mục đích là để đảm bảo số lượng người tối thiểu có thể tìm hiểu thông tin tại mỗi Level. Compartments là các Categories - nhóm Data với một số lượng Subjects hạn chế có thể truy cập đến Data tại mỗi Level. Compartmented Mode Workstations [CMWs] cho phép người dùng xử lý Multiple Compartments of Data cùng một lúc, nếu họ có Clearance cần thiết.

Multilevel Security Mode

Một hệ thống được xem là đang vận hành trong Multilevel Security Mode, khi nó cho phép 2 hoặc nhiều Classification Levels của thông tin có thể được xử lý cùng một lúc, khi không phải ai cũng đều có Clearance hoặc Formal Approval để truy cập đến tất cả thông tin được xử lý bởi hệ thống. Cho nên tất cả mọi người dùng cần phải có Formal Approval, NDA, Need-to-know và Clearance cần thiết để truy cập đến Data mà họ cần cho công việc của họ.

Trong Mode này, người dùng không thể nào truy cập đến tất cả Data trong hệ thống, chỉ được truy cập đến những gì dành cho người đó mà thôi. Bell-LaPadula Model là một ví dụ về Multilevel Security Model, bởi vì nó xử lý Multiple Information Classifications ở nhiều Security Levels khác nhau bên trong một hệ thống cùng một lúc.

Guards

Software Guards và Hardware Guards cho phép việc trao đổi dữ liệu giữa Trusted [high assurance] và Less Trusted [low assurance] Systems và Environments. Giả sử chúng ta đang làm việc trên một hệ thống MAC [hoạt động trong Dedicated Security Mode of Secret] và chúng ta cần communicate với một MAC Database [hoạt động trong Multilevel Security Mode với Top-Secret]. Hai hệ thống này cung cấp các Protection Levels khác nhau.

Như đã nói qua trước đây, nếu một hệ thống Lower Assurance có thể communicate trực tiếp với một hệ thống Higher Assurance, khi đó các lỗ hổng bảo mật và những sự xâm hại có thể sẽ xuất hiện. Cho nên, Software Guard có thể được triển khai, thực sự nó chỉ là một sản phẩm Front-End cho phép Interconnectivity - Kết nối liên thông giữa các hệ thống đang hoạt động tại những Security Levels khác nhau. [Các loại Guards khác nhau có thể thực hiện Filtering, Processing Requests, Data Blocking và Data Sanitization.]

Hoặc Hardware Guard có thể được triển khai, đó là một hệ thống với 2 NICs Card kết nối hai hệ thống cần communicate với nhau. Guard là một phần add-on mà cung cấp mức độ Access Control chặt chẽ giữa các hệ thống khác nhau. Guard chấp nhận các Requests từ một hệ thống Lower Assurance, reviews requests để đảm bảo nó được allowed, sau đó sẽ submit request đến hệ thống Higher Assurance. Mục đích là để đảm bảo thông tin không low từ một High Security Level xuống một Low Security Level theo một cách trái phép.

Guards có thể được sử dụng để kết nối các hệ thống MAC khác nhau hoạt động trong những Security Modes khác nhau và Guards còn có thể được sử dụng để kết nối các Networks khác nhau hoạt động trong những Security Levels khác nhau. Trong nhiều trường hợp, Less Trusted System có thể "send messages" đến More Trusted System nhưng chỉ có thể nhận lại Acknowledgments. Điều này phổ biến khi E-mail Message cần được gửi đi từ Less Trusted Systems đến More Trusted Systems.

Trust and Assurance - Độ Tin Cậy và Độ Đảm Bảo

Như đã thảo luận trước đây trong phần "Trusted Computing Base", không một hệ thống nào thực sự Secure, bởi vì nếu có đủ nguồn lực, thời gian, những kẻ tấn công đều có thể làm tổn thương đến hầu hết mọi hệ thống bằng cách này hoặc cách khác; Tuy nhiên, các hệ thống có thể cung cấp Levels of Trust - Mức Độ Tin Cậy. Trust Level có thể nói cho khách hàng biết : Có bao nhiêu sự bảo vệ mà anh ta có thể mong đợi được từ hệ thống này, cũng như sự đảm bảo mà hệ thống sẽ hoạt động chính xác và theo một cách có thể đoán trước được trong mọi tình huống.

TCB bao gồm tất cả các cơ chế bảo vệ bên trong một hệ thống : Software, Hardware, Firmware. Tất cả những cơ chế này cần làm việc theo một cách Orchestrated - Đã được sắp đặt để thực thi tất cả những yêu cầu của Security Policy. Khi Evaluated - Được đánh giá, những cơ chế này sẽ được Tested, các Designs của chúng sẽ được Inspected - Xem xét và các tài liệu [documentation] hỗ trợ của chúng sẽ được Reviewed và Evaluated.

Làm thế nào để hệ thống được phát triển, làm thế nào để hệ thống được duy trì và thậm chí là làm thế nào để cung cấp chúng đến khách hàng, đó là tất cả những gì sẽ được Reviewed khi Trust - Độ Tin Cậy của một hệ thống đang được đánh giá [gauged]. Tất cả các thành phần này sẽ được đưa vào một Evaluation Process - Quá Trình Đánh Giá và được gán cho một Assurance Rating, điều đó đại diện cho Trust Level và Assurance Level của hệ thống đã được đánh giá thẩm định. Khách hàng khi đó sẽ sử dụng Rating này để xác định xem hệ thống nào phù hợp nhất với những yêu cầu Security của họ.

Assurance và Trust đều tương tự nhau trong tự nhiên, nhưng chúng hơi khác nhau trong Product Ratings. Trong một Trusted System , tất cả các cơ chế bảo vệ cùng làm việc với nhau để xử lý dữ liệu nhạy cảm đối với nhiều dạng Uses - Sử dụng [chú ý là use chứ không phải du sờ nhé!] và cung cấp Protection Level cần thiết cho mỗi Classification Level. Assurance cũng xem xét các vấn đề tương tự nhưng chi tiết hơn và sâu hơn.

Những hệ thống cung cấp Higher Assurance Levels đều đã được thử nghiệm, kiểm tra rộng rãi, các Designs của chúng đều đã được xem xét kỹ [inspected], giai đoạn phát triển của chúng đã được Reviewed và Technical Specification và Test Plans của chúng đều đã được thẩm định.

Bạn có thể mua một chiếc xe và bạn có thể Trust nó, nhưng có thể bạn sẽ có cảm giác sâu xa hơn về Assurance - Độ đảm bảo của Trust - Độ Tin Cậy của chiếc xe đó, nếu bạn biết được chiếc xe này đã được sản xuất như thế nào, nó đã được tích hợp những gì, ai sản xuất ra nó, những cuộc kiểm tra nào mà nó đã thông qua và hiệu năng của nó như thế nào trong những tình huống khác nhau ...

Trong Trusted Computer System Evaluation Criteria [TCSEC] - Tiêu Chuẩn Đánh Giá Hệ Thống Máy Tính Đáng Tin Cậy, thường được gọi là Orange Book, Lower Assurance Level Ratings chỉ xem xét các cơ chế bảo vệ của một hệ thống và kết quả thử nghiệm [testing results] để đưa ra một Assurance Rating, nhưng đối với Higher Assurance Level Rating, nó sẽ xem xét nhiều thứ hơn, chẳng hạn như : system design, specifications, development procedures, supporting documentation và testing results.

Các cơ chế bảo vệ trong Higher Assurance Level System có thể sẽ không khác biệt nhiều lắm so với Lower Assurance Level System, nhưng cách chúng được thiết kế và xây dựng sẽ được xem xét kỹ [scrutiny] hơn.

Systems Evaluation Methods - Những Phương Pháp Thẩm Định Hệ Thống

Security Evaluation - Thẩm Định An Ninh sẽ kiểm tra các thành phần có liên quan đến Security của một hệ thống, có nghĩa là TCB, là các cơ chế Access Control, là Reference Monitor, là Kernel và Protection Mechanisms. Relationship - Mối Quan Hệ và Interaction - Sự Tương Tác giữa các thành phần này cũng sẽ được thẩm định. Có nhiều phương pháp khác nhau để thẩm định và gán [assigning] Assurance Levels cho các hệ thống.

Có 2 lý do để giải thích tại sao có nhiều hơn một Assurance Evaluation Process - Quá Trình Thẩm Định Độ Đảm Bảo tồn tại :

1. Các phương pháp và các Ideologies - Ý Thức Hệ đã không ngừng tiến hóa theo thời gian. 2. Các thành phần khác nhau của thế giới có cái nhìn về Computer Security khác nhau, cũng như có sự đánh giá một số khía cạnh an ninh khác nhau.

Mỗi phương pháp đều sẽ được giải thích và được so sánh rõ ràng để chúng ta có thể hiểu được.

Why Put a Product Through Evaluation ? Tại sao phải đưa sản phẩm thông qua một cuộc thẩm định ?

Việc gửi một sản phẩm để được đánh giá theo Orange Book, Information Technology Security Evaluation Criteria, hoặc Common Criteria không phải là một chuyện dễ dàng đối với các Vendors. Trong thực tế, nó là một quá trình vô cùng "đau đớn" và "dài đăng đẳng". Vì vậy, trước khi chúng ta đi xuyên qua các Criteria khác nhau này, chúng ta hãy xem xét lý do tại sao bất cứ Vendor nào cũng muốn "đặt sản phẩm của mình" vào quá trình này.

Nếu chúng ta đang có nhu cầu mua sắm Firewall, làm thế nào bạn biết được mức độ bảo vệ mà các sản phẩm cung cấp, cũng như sản phẩm nào là tốt nhất, phù hợp nhất cho môi trường doanh nghiệp của bạn ? Chúng ta có thể lắng nghe lời quảng cáo tiếp thị của Vendor, tin tưởng vào nhân viên bán hàng, người sẽ nói cho chúng ta biết rằng sản phẩm của họ sẽ giải quyết được tất cả mọi vấn đề trong cuộc sống của chúng ta !

Hoặc chúng ta có thể "lắng nghe" lời khuyên của một tổ chức thứ 3, một tổ chức độc lập chuyên thực hiện việc kiểm tra, xem xét độ đảm bảo của các sản phẩm mà chúng ta quan tâm, họ không có bất kỳ sự thiên vị cho một sản phẩm cụ thể nào cả. Nếu chúng ta chọn Option này, khi đó chúng ta sẽ tham gia vào một thế giới của những người làm việc bên trong lĩnh vực Assurance Ratings - Xếp Hạng Độ Đảm Bảo.

Tại Hoa Kỳ, National Computer Security Center [NCSC] là một tổ chức thuộc National Security Agency [NSA], chịu trách nhiệm thẩm định các hệ thống Máy Tính và các sản phẩm. Họ có một nhóm, được gọi là Trusted Product Evaluation Program [TPEP], giám sát việc thử nghiệm bởi các tổ chức thẩm định [đã được NCSC phê duyệt] sản phẩm thương mại đối với một tập hợp Criteria cụ thể.

Cho nên, khi Vendor tạo ra một sản phẩm và gửi nó đến một tổ chức thẩm định [đã được NCSC phê duyệt] phù hợp với TPEP Guidelines. Tổ chức thẩm định đó sẽ có một nhóm Testers, những người sẽ tuân theo một Set of Criteria [nhiều năm về trước nó là Orange Book nhưng bây giờ nó đang chuyển dần về Common Criteria] để kiểm tra, thẩm định sản phẩm của Vendor. Sau khi thẩm định xong, sản phẩm sẽ được gán cho một Assurance Rating.

Cho nên thay vì tin vào lời quảng cáo Marketing của Vendor, chúng ta nên tìm hiểu, tham khảo thông tin từ một bên thứ 3 đã đánh giá sản phẩm thì tốt hơn.

Quá trình đánh giá này rất tốn kém và mất nhiều thời gian. Không phải Vendors nào cũng đưa sản phẩm của họ thông qua quá trình này, bởi vì chi phí và sự trì hoãn ngày ra mắt thị trường sẽ rất lâu. Thông thường, Vendor sẽ đưa sản phẩm của họ thông qua quá trình này nếu khách hàng "ruột" của họ có hơi hướng ra quyết định mua hàng dựa trên Assurance Ratings. Tại Hoa Kỳ, Bộ Quốc Phòng [DoD] là một khách hàng vô cùng to lớn, cho nên hầu hết các Vendors đều đưa sản phẩm chính của họ xuyên qua quá trình thẩm định này, với hy vọng rằng Bộ Quốc Phòng sẽ mua sản phẩm của họ.

The Orange Book

U.S. Department of Defense - Bộ Quốc Phòng Mỹ đã phát triển ra Trusted Computer System Evaluation Criteria [TCSEC], được sử dụng để thẩm định Hệ Điều Hành, Applications và các sản phẩm khác. Evaluation Criteria - Những Tiêu Chuẩn Đánh Giá này đã được công bố trong một cuốn sách có bìa màu da cam, được gọi là Orange Book - Sách Cam.

Các khách hàng sử dụng Assurance Rating mà Criteria hiện nay cung cấp như một thước đo khi so sánh các sản phẩm khác nhau. Criteria còn cung cấp hướng dẫn cho các nhà sản xuất, để họ biết được những Specifications nào cần xây dựng, và cung cấp một quá trình thẩm định One-stop *một cửa*.

The Orange Book được sử dụng để đánh giá xem liệu sản phẩm có chứa các Security Properties - Thuộc Tính Bảo Mật mà nhà cung cấp đã tuyên bố hay không và liệu sản phẩm có thích hợp đối với một Application hoặc một Function cụ thể hay không. Orange Book được sử dụng để Review các chức năng - functionality, tính hiệu quả - effectiveness và độ đảm bảo - assurance của một sản phẩm trong quá trình thẩm định của nó, đồng thời Orange Book cũng sử dụng các Classes để đưa ra những cách giải quyết điển hình cho các yêu cầu bảo mật.

TCSEC cung cấp một Classification System - Hệ Thống Phân Loại được chia thành các thứ bậc của Assurance Levels :

1. Verified protection
2. Mandatory protection
3. Discretionary protection
4. Minimal security

Classification A đại diện cho mức độ Assurance cao nhất ! Còn Classification D đại diện cho mức độ Assurance thấp nhất.

Mỗi Division - Phân cấp có thể có 1 hoặc nhiều Numbered Classses tương ứng với một tập hợp các yêu cầu - Sef of Requirements mà cần phải đáp ứng đối với một hệ thống để đạt được một Rating cụ thể. Classes với con số càng cao thì cung cấp mức độ Trust và Assurance càng lớn. Cho nên B2 sẽ cung cấp mức độ Trust nhiều hơn B1, và C2 sẽ cung cấp mức độ Trust nhiều hơn C1.

Criteria - Tiêu Chuẩn bao gồm 4 chủ đề chính [main topics] : Security Policy, Accountability, Assurance và Documentation--- nhưng thực sự chúng tách nhỏ ra thành 7 chủ đề khác nhau :

• Security policy : Policy bắt buộc phải Explicit - Rõ ràng, được xác định kỹ và được thực thi bởi các cơ chế bên trong hệ thống.

• Identification : Cá nhân mỗi Subjects bắt buộc phải có Uniquely Identified - Danh Tính Độc Nhất.

• Labels : Access Control Labels bắt buộc phải được Associated - Liên Kết đúng với các Objects.

• Documentation : Documentatin bắt buộc phải được cung cấp, bao gồm cả Test, Design và Specification Documents, User Guides và Manuals.

• Accountability : Audit Data bắt buộc phải được Captured và được bảo vệ để thực thi Accountability.

• Life-cycle Assurance : Software, Hardware và Firmware bắt buộc phải được kiểm tra [tested] riêng lẻ, để đảm bảo rằng mỗi thứ có thể thực thi Security Policy một cách hiệu quả trong suốt vòng đời [lifetimes] của chúng.

• Continuous Protection : Các cơ chế bảo mật và hệ thống như một tổng thể bắt buộc phải hoạt động theo một cách có thể Predictably - Đoán trước được và Acceptably - Chấp nhận được trong những tình huống khác nhau liên tục diễn ra.

Những phân loại [categories] đã kể trên đây được thẩm định độc lập, nhưng Rating được gán ở phút chót sẽ không phải là Rating riêng biệt cho một phân loại nào cả. Rating là một sự tổng hợp của tất cả những hạng mục trên.

Mỗi Division và Class là sự kết hợp các yêu cầu của những Phân Cấp và Lớp bên dưới nó. Xem qua ví dụ cho dễ hiểu, điều này có nghĩa là C2 bắt buộc phải đáp ứng được tất cả các yêu cầu Criteria của chính bản thân nó và tất cả các yêu cầu [requirements] của C1. B3 bắt buộc phải đáp ứng đầy đủ các yêu cầu của chính bản thân nó và tất cả các yêu cầu của C1, C2, B1 và B2.

Mỗi Division hoặc Class ở Phía Trên [Up] bắt buộc phải thực hiện được các Security Requirements của chính bản thân nó và của tất cả các Classes cũng như Divisions bên dưới nó.

Vì vậy, khi một Vendor gửi sản phẩm của họ đến một cuộc thẩm định, họ sẽ trình nó đến NCSC. Nhóm giám sát các quá trình Evaluation được gọi là Trusted Products Evaluation Program [TPEP]. Sản phẩm được thẩm định hoàn tất sẽ được đặt trên Evaluated Product List [EPL] với Rating tương ứng của chúng. Khi người tiêu dùng quan tâm đến một sản phẩm hoặc một hệ thống nào đó, họ có thể kiểm tra danh sát EPL để tìm ra Rating được gán cho sản phẩm hoặc hệ thống đó.

Isn’t the Orange Book Dead ? Không phải Sách Cam đã tiêu từ lâu rồi sao ?

Chúng ta đang di chuyển từ Orange Book sang Common Criteria, cho nên có một câu hỏi phổ biến : "Vậy tại sao tôi phải học về Orange Book ?" . Chỉ vì chúng ta đang trong quá trình chuyển đổi, không có nghĩa là Orange Book không quan trọng. Nó là First Evaluation Criteria - Tiêu Chuẩn Thẩm Định Đầu Tiên và đã được sử dụng trong 20 năm. Rất nhiều thuật ngữ và các khái niệm cơ bản đều bắt nguồn từ Orange Book. Và chúng ta vẫn có một số sản phẩm sử dụng Ratings này, cuối cùng chúng cũng thông qua quá trình thẩm định Common Criteria.

Kỳ thi CISSP di chuyển đều đặn từ Orange Book đến Common Criterial, nhưng Orange Book không được nêu ra.

Đối với một số độc giả, cuốn sách này chỉ như một sự bổ sung, nhắc lại về mặt kiến thức chuyên môn đơn giản nhẹ nhàng, một số độc giả này đã biết rất rõ về các khái niệm này. Nhưng cũng có một số độc giả, họ gặp nhiều khó khăn và thách thức vì những khái niệm mới mẻ này. Nếu những điều này mới mẻ với bạn, thì bạn chính là "newbie" trong lĩnh vực ATTT.

Điều đó vẫn ok, nhưng hãy nhớ rằng tuy cuốn sách này quá chi tiết nhưng những gì chúng ta hiểu được ngày hôm nay sẽ vô cùng có lợi, bởi vì nó mở rộng sâu sắc sự hiểu biết của chúng ta ra rất nhiều, thay vì chỉ học thuộc lòng để đi thi.

Division D: Minimal Protection | Phân Cấp D : Bảo Vệ Tối Thiểu

Chỉ có 1 Class - Phân Lớp duy nhất tại Division D. Nó được dành riêng cho các hệ thống đã trải qua cuộc thẩm định nhưng thất bại, không đáp ứng được Criteria và Requirements của các Divisions cao hơn.

Division C: Discretionary Protection | Phân Cấp C : Bảo Vệ Tùy Ý

Loại Rating C có 2 Assurance Ratings bên trong nó, được mô tả sau đây. Con số Assurance Rating càng cao thì sự bảo vệ càng lớn.

C1: Discretionary Security Protection - Bảo Vệ An Ninh Tùy Ý

Discretionary Access Control dựa trên các cá nhân hoặc các nhóm. Nó đòi hỏi một sự tách biệt của Users và Information, và Identification và Authentication của các thực thể cá nhân. Một số loại Access Control là cần thiết, để người dùng có thể đảm bảo dữ liệu của họ sẽ không bị truy cập và bị làm hỏng bởi những người khác.

System Architecture bắt buộc phải cung cấp một Protected Execution Domain để Privileged System Processes không bị ảnh hưởng tiêu cực bởi các Lower-Privileged Processes. Cần phải có những cách cụ thể để Validating - Xác Nhận tính toàn vẹn vận hành của hệ thống. Documentation Requirements - Các tài liệu yêu cầu phải có bao gồm : Design Documentation, nó chỉ ra cho thấy hệ thống đã được xây dựng như thế nào, bao gồm những cơ chế bảo vệ nào, Test Documentation [test plan và kết quả], Facility Manual [tài liệu hướng dẫn cài đặt và cấu hình hệ thống], User Manual [hướng dẫn sử dụng hệ thống].

Loại môi trường mà đòi hỏi Rating này, thì trong đó Users và Processing Information có cùng một Sensitivity Level; Do đó, Strict Access Control - Kiểm Soát Truy Cập Chặt Chẽ và các biện pháp Auditing sẽ không bắt buộc. Nó sẽ là một Trusted Environment với Low Security Concerns - Những Mối Quan Ngại Về Bảo Mật thấp.

C2: Controlled Access Protection - Bảo Vệ Truy Cập Có Kiểm Soát

Users cần được Identified Individually - Định danh Riêng Biệt để cung cấp kiểm soát truy cập chính xác hơn và cung cấp khả năng Auditing. Các cơ chế Technical Access Control được sử dụng để thực thi Authentication và Uniquess - Tính Duy Nhất trong Idenfication của mỗi cá nhân.

Các Events có liên quan đến Security sẽ được Audited, và những Records này bắt buộc phải được bảo vệ khỏi những sự thay đổi trái phép. Architecture bắt buộc phải cung cấp Resource hoặc Object, Isolation - Cô Lập để sự bảo vệ thích hợp có thể được áp dụng đến Resource và bất kỳ hoạt động nào diễn ra trên nó [ý nói Resource] cũng đều sẽ được Audited.

Khái niệm Object Resuse - Tái sử dụng Object cũng phải được gọi đến, có nghĩa là bất kỳ sự nắm giữ dữ liệu nào cũng không được phép chứa "tàn tích thông tin - information remnants" sau khi nó được Released cho một Subject khác sử dụng. Nếu Subject sử dụng một Memory Segment, thì Memory Space không được phép lưu lại bất kỳ thông tin nào cả sau khi Subject hoàn thành việc sử dụng nó.

C2 Class yêu cầu một phương pháp cung cấp Access Control chi tiết hơn. Hệ thống cần phải thực thi Strict Logon Procedures và cung cấp khả năng ra quyết định [decision-making] khi Subjects yêu cầu truy cập đến Objects. C2 System không thể đảm bảo nó sẽ không bị tổn hại, nhưng nó cung cấp một mức độ bảo vệ khiến cho những sự cố gắng xâm hại sẽ trở nên khó khăn hơn để thực hiện được.

Loại môi trường mà đòi hỏi Rating C2, thì trong đó tuy các Users được Trusted nhưng một mức độ Accountability nào đó là bắt buộc phải có. Rating C2, về tổng thể được xem như là một Class hợp lý nhất dành cho các Applications thương mại, nhưng mức độ bảo vệ của C2 vẫn còn tương đối yếu.

Division B: Mandatory Protection | Phân Cấp B: Bảo Vệ Bắt Buộc

Mandatory Access Control - Kiểm soát truy cập bắt buộc được thực thi bằng cách sử dụng Security Labels. Architecture dựa trên Bell-LaPadula Security Model và bằng chứng của việc thực thi Reference Monitor phải Available.

B1: Labeled Security

Mỗi Object bắt buộc phải có một Classification Label và mỗi Subject bắt buộc phải có một Clearance Label. Khi Subject truy cập đến Object, hệ thống cần phải so sánh các Security Labels của Subject và Object để đảm bảo hoạt động đã yêu cầu có thể chấp nhận được. Data rời khỏi hệ thống bắt buộc cũng phải chứa một Security Label chính xác. Security Policy dựa trên một Informal Statement - Tuyên Bố Không Chính Thức, và các Design Specifications cần được Reviewed và Verified.

B1 Rating dành cho các môi trường mà yêu cầu hệ thống xử lý Classified Data.Chú ý : Security Labels không bị bắt buộc [not required] cho đến khi xuất hiện Security Rating B; Do đó, C2 không bị bắt buộc phải có Security Labels nhưng B1 thì bắt buộc.

B2 : Structured Protection

Security Policy được xác định rõ ràng và được Documented, System Design & Implementation là đối tượng để xem xét kỹ lưỡng và Testing Procedures. Class này đòi hỏi các cơ chế xác thực nghiêm ngặt hơn và xác định rạch ròi các Interfaces giữa các Layers. Subjects và Devices đều đòi hỏi phải có Labels, hệ thống bắt buộc không được cho phép có Covert Channels.

Trusted Path cho các tiến trình Logon và Authentication bắt buộc phải được đưa vào, có nghĩa là Subjects tương tác trực tiếp đến Applications hoặc HĐH, không được để Trapdoors tồn tại. Không có cách nào để phá vỡ hoặc xâm hại Communication Channel này. Các chức năng điều hành [operator] và quản lý [administration] cần được Seperated - Phân tách bên trong hệ thống, để cung cấp thêm Độ Tin Cậy [trusted] và bảo vệ cho các chức năng hoạt động.

Distinct Address Spaces - Các địa chỉ riêng biệt cần phải được cung cấp để Isolate - Cô Lập các Processes, Covert Channel Analysis cần phải được thực hiện. B2 Class bổ sung thêm Assurance - Độ Đảm Bảo bằng cách thêm requirements đối với việc thiết kế hệ thống.

Loại môi trường mà đòi hỏi B2 Rating, thì các Processes dữ liệu nhạy cảm sẽ đòi hỏi một mức độ bảo mật cao hơn. Loại môi trường này sẽ đòi hỏi các hệ thống phải có tính "đề kháng" tương đối đối với sự xâm nhập và sự thỏa hiệp [penetration and compromise].

B3: Security Domains

Trong Class này, mỗi cơ chế bảo mật được cung cấp càng chi tiết và Programming Code không cần thiết để hỗ trợ Security Policy nên được loại trừ [excluded]. Việc thiết kế và triển khai thực hiện không nên cung cấp quá nhiều sự phức tạp, bởi vì nếu như hệ thống càng phức tạp, thì kỹ năng của các nhân sẽ phải tăng lên, những người chịu trách nhiệm Test, Maintain, và Configure nó; Do đó, an ninh tổng thể có thể bị đe dọa.

Các thành phần Reference Monitor bắt buộc phải đủ nhỏ để kiểm tra đúng cách và để tamper-proof - chống lục lọi trộm cắp. Vai trò Security Administrator được xác định rõ ràng, hệ thống bắt buộc phải có khả năng Recover - Phục Hồi từ những sự hỏng hóc mà Security Level của nó không bị tổn hại [compromised].

Khi hệ thống khởi động và tải HĐH với các thành phần của nó, hệ thống bắt buộc phải thực hiện điều đó trong Initial Secure State - Trạng Thái An Toàn Lúc Ban Đầu, để đảm bảo rằng bất kỳ điểm yếu [weakness] nào của hệ thống cũng không bị lợi dụng trong thời gian "nhạy cảm" này.

Loại môi trường mà B3 Systems yêu cầu là môi trường được bảo mật cao - Highly Secured, xử lý những thông tin rất nhạy cảm. Nó đòi hỏi hệ thống phải có sức đề kháng - resistant rất cao [highly] để chống lại những sự xâm nhập.

Division A: Verified Protection

Những phương pháp chính thức được sử dụng để đảm bảo rằng tất cả các Subjects và Objects đều được kiểm soát với Discretionary và Mandatory Access Controls. Design, Development, Implementation và Documentation được xem xét một cách cụ thể, chi tiết và chính thức [formal]. Các cơ chế an ninh giữa B3 và A1 không khác nhau bao nhiêu cả, nhưng cách hệ thống đã được thiết kế và đã được phát triển sẽ được thẩm định theo một Procedure có cấu trúc hơn [more structured] và nghiêm ngặt hơn.

A1: Verified Design

Architecture và các tính năng bảo vệ không có nhiều khác biệt so với những hệ thống đã đạt B3 Rating, nhưng Assurance - Độ đảm bảo của hệ thống đã đạt A1 Rating cao hơn so với hệ thống B3 Rating bởi vì Formality - Hình thức trong cách hệ thống A1 đã được thiết kế, cách specifications đã được phát triển và mức độ chi tiết trong Verification Techniques - Kỹ Thuật Xác Minh.

Formal Techniques - Các kỹ thuật chính thức được sử dụng để chứng minh Equivalence - Sự Tương Đương giữa TCB Specifications và Security Policy Model. Change Configuration nghiêm ngặt hơn được đặt vào trong lúc phát triển hệ thống A1 Rating, thiết kế tổng thể có thể được Verified. Trong nhiều trường hợp, thậm chí cách thức mà hệ thống được chuyển đến cho khách hàng cũng bị dò xét nghiêm ngặt, để đảm bảo không có bất kỳ sự tổn hại nào xảy ra cho hệ thống khi nó đang đến đích.

Loại môi trường mà yêu cầu hệ thống đạt Rating A1 là loại môi trường An toàn trong an toàn nhất ! Siêu An toàn ! Đây là loại môi trường chuyên dành để xử lý các thông tin Top-Secret và không Trust vào bất kỳ một ai đang sử dụng hệ thống mà không authentication, restrictions và auditing.Chú ý : TCSEC giải quyết Confidentiality, nhưng không giải quyết Integrity. Functionality - Chức năng của các cơ chế an ninh và Assurance - Độ đảm bảo của các cơ chế này không được thẩm định một cách riêng biệt, thay vào đó là một sự kết hợp, một sự kết hợp thẩm định tổng thể.

The Orange Book and the Rainbow Series Tại sao có nhiều màu sắc trong cầu vòng ? Phản hồi : Bởi vì có nhiều loại sản phẩm cần được Evaluated.

Orange Book chủ yếu là giải quyết các yêu cầu và những mong đợi của chính phủ, tổ chức quân sự dành cho hệ thống máy tính của họ. Nhiều người làm trong lĩnh vực ATTT đã chỉ ra những thiếu sót trong Orange Book, đặc biệt là khi nó đang được áp dụng cho các hệ thống trong những lĩnh vực thương mại thay vì các tổ chức chính phủ. Danh sách dưới đây. Danh sách sau đây là một bảng tóm tắt về những vấn đề gây phiền phức mà các học viên ATTT đã bày tỏ về Orange Book :

• Có vẻ như nó chỉ quan tâm đặc biệt đến HĐH, không có bất kỳ điều gì liên quan đến Networking, Database, hay những thứ khác ..... • Nó chỉ tập trung chủ yếu vào 1 thuộc tính Security duy nhất : Confidentiality, hai chú em Integrity và Availability thì bị bỏ rơi mất tiêu rồi ..... • Nó hoạt động với Government, Military Classifications chứ không sử dụng cho Commercial Classifications. • Nó chỉ có một số lượng Ratings tương đối nhỏ, điều đó có nghĩa là nhiều khía cạnh khác của Security sẽ không được thẩm định [evaluated] và được đánh giá một cách độc lập [rated independently].

Orange Book nhấn mạnh vào việc Controlling - Kiểm soát người dùng truy cập hệ thống và hầu như bỏ qua việc kiểm soát những gì người dùng có thể làm với thông tin khi họ đã được Authorized. Authorized Users - Người dùng đã được ủy quyền có thể & thường gây ra thiệt hại nhiều cho dữ liệu hơn so với những kẻ tấn công bên ngoài. Các tổ chức thương mại đã bày tỏ mối quan tâm lớn nhất của họ là về Integrity - Tính toàn vẹn của dữ liệu, trong khi đó các tổ chức quân sự đặt mối quan tâm hàng đầu của họ là Confidentiality - Tính bảo mật.

Bởi vì những mục tiêu khác nhau này nên Orange Book là một Evaluation Tool - Công Cụ Thẩm Định tốt hơn nên dành cho các hệ thống chính phủ và tổ chức quân sự.

Bởi vì Orange Book chỉ tập trung vào HĐH, nên có rất nhiều khía cạnh Security khác bị bỏ ra khỏi Orange Book. Orange Book cung cấp một Framework cho việc Building và Evaluating Trusted Systems. Vì thế cho nên, càng có nhiều cuốn sách đã được viết ra để mở rộng phạm vi của Orange Book vào bên trong những lĩnh vực khác của ATTT. Những quyển sách này cung cấp thông tin chi tiết hơn, diễn giải một số yêu cầu của Orange Book và mô tả Evaluation Processes. Những quyển sách này được gọi chung là Rainbow Series bởi vì chúng có những trang bìa mang nhiều màu sắc khác nhau.

The Red Book

Orange Book giải quyết Single-System Security, nhưng Networks là một sự kết hợp của nhiều hệ thống, và mỗi Network cần được an toàn mà không phải hoàn toàn Trust đến từng hệ thống đã kết nối với nó. Trusted Network Interpretation [TNI], còn được gọi là Red Book. Bởi vì màu trang bìa của nó là màu đỏ, nó giải quyết những vấn đề về Security Evaluations - Thẩm Định An Ninh dành cho Networks và các thành phần Networks. Nó giải quyết những hệ thống mạng LAN và WAN đã bị cô lập [isolated].

Giống như Orange Book, Red Book không cung cấp chi tiết cụ thể về cách làm thế nào để triển khai các cơ chế bảo mật. Thay vào đó, nó cung cấp một Framework dành cho việc bảm đảm các loại Networks khác nhau. Network đã có Security Policy, Architecture và Design, cũng như HĐH. Subjects đang truy cập đến Objects trên Networks cần được Controlled - Kiểm Soát, Monitored - Giám Sát và Audited. Trong Network, Subject có thể là một máy Workstation và Object có thể là một Network Service nằm trên Server.

Encryption và Protocols là những thành phần mà cung cấp rất nhiều Security bên trong Network, ngoài ra còn đo lường các chức năng, sức mạnh và độ đảm bảo Red Book.

Sau đây là một cái nhìn tổng quan về các hạng mục Security được đề cập đến trong Red Book - Sách "Đỏ" :

• Communication integrity

• Authentication : Bảo vệ chống lại các cuộc tấn công Masquerading - Giả Mạo và Playback. Các cơ chế bảo vệ bao gồm Digital Signatures, Encryption, Timestamp và Passwords.

• Message integrity : Bảo vệ Protocol Header, Routing Information và Packet Payload khỏi sự thay đổi trái phép. Các cơ chế bảo vệ bao gồm Message Authentication và Encryption.

• Nonrepudiation [chống chối bỏ] : Đảm bảo rằng Sender - Người gửi Message không thể chối bỏ việc anh ta chính là người gửi message đi. Các cơ chế để thực hiện việc đó bao gồm Encryption, Digital Signatures và Notarization - Công chứng.

• Denial-of-service prevention

• Continuity of operations : Đảm bảo rằng Network luôn Available ngay cả khi đã bị tấn công. Các cơ chế để thực hiện điều đó bao gồm Fault-tolerant và các hệ thống Redundant, Capability - Khả năng để Reconfigure Network Parameters trong trường hợp khẩn cấp.

• Network management : Giám sát Network Performance và xác định các cuộc tấn công cũng như những sự hỏng hóc. Các cơ chế để thực hiện điều đó bao gồm những thành phần mà cho phép Network Administrators giám sát và hạn chế truy cập Resource.

• Compromise protection

• Data confidentiality : Bảo vệ dữ liệu khỏi những sự truy cập trái phép trong quá trình truyền tải. Các cơ chế để thực hiện điều đó bao gồm Access Controls, Encryption và Physical Protection đường dây Cables.

• Traffic flow confidentiality : Đảm bảo rằng không có bất kỳ đối tượng trái phép nào biết được Routing Information hoặc Frequency của Communication qua việc Traffic Analysis. Các cơ chế bao gồm Padding Message, Sending Noise hoặc Sending False Messages.

• Selective routing : Routes Messages là một cách để tránh các Threats cụ thể. Các cơ chế bao gồm Network Configuration và Routing Tables.

Assurance - Độ đảm bảo có thể nhận được bằng cách Testing Configurations trong nhiều kịch bản khác nhau, Evaluating - Thẩm định thực tiễn công nghệ [engineering practices] ,Validating - Xác minh và Verifying - Xác nhận các yêu sách về Security.

TCSEC đã được giới thiệu vào năm 1985 và được "nghỉ hưu" vào tháng 12 năm 2000. Nó là một Set of Standards - Tập hợp các tiêu chuẩn đầu tiên có phương pháp và logic được phát triển để đảm bảo an toàn cho các hệ thống máy tính. Nó có ảnh hưởng rất nhiều đến một số quốc gia mà Evaluation Standards của họ dựa trên TCSEC Guidelines. TCSEC cuối cùng đã được hay thế bằng Common Criteria - Tiêu Chuẩn Chung.

Information Technology Security Evaluation Criteria

Information Technology Security Evaluation Criteria [ITSEC] là nỗ lực đầu tiên trong việc thiết lập một Single Standard dành cho việc thẩm định các thuộc tính Security của những hệ thống máy tính và các sản phẩm ở nhiều nước Châu Âu - European. Hoa Kỳ ngắm đến Orange Book và Rainbow Series, Châu Âu sử dụng ITSEC để thẩm định và đánh giá [rate] các hệ thống máy tính. [Ngày nay, tất cả mọi người đều đã di chuyển sang Common Criteria, sẽ được giải thích ở phần sau].

ITSEC thẩm định Two Main Attributes - 2 Thuộc Tính Chính của các cơ chế bảo vệ hệ thống : Functionality và Assurance.

Khi Functionality của các cơ chế bảo vệ hệ thống được thẩm định, các Services được cung cấp đến Subjects [các cơ chế Access Control, Auditing, Authentication, vân vân] sẽ được kiểm tra và đo lường [measured]. Functionality - Tính năng của cơ chế bảo vệ có thể rất đa dạng bởi vì hệ thống đã được phát triển để cung cấp nhiều Functionality khác nhau đến người dùng. Tuy nhiên, khi Functionality được thẩm định, nó được thử nghiệm để xem có những Functionality nào mà Vendor tuyên bố họ cung cấp.

Assurance, về mặt khác là Degree of Confidence - Độ Tin Cậy của các cơ chế bảo vệ, hiệu quả và khả năng của chúng để thực hiện tính nhất quán [consistenly]. Assurance, thông thường được kiểm tra bằng cách Examining - Kiểm tra Development Practices, Documentation, Configuration Management và Testing Mechanisms.

Có thể có 2 cơ chế bảo vệ của hệ thống cùng cung cấp một loại Functionalities và có Assurance Levels rất khác nhau. Điều này là bởi vì các cơ chế về cơ bản cung cấp Functionality có thể được phát triển, được thiết kế và thực hiện khác nhau. Hệ thống A và Hệ thống B có thể có các cơ chế bảo vệ cung cấp cùng một loại Functionality cho việc Authentication, trong trường hợp đó cả hai sản phẩm có thể sẽ nhận được cùng một mức Rating dành Functionality. Nhưng các nhà phát triển của Hệ thống A có thể rất cẩu thả và bất cẩn khi phát triển cơ chế Authentication của họ, trong trường hợp đó sản phẩm của họ sẽ nhận được Lower Assurance Rating so với Hệ thống B.

ITSEC [của Châu Âu] thực sự tách biệt 2 thuộc tính này [functionality và assurance] và cũng đánh giá chúng riêng biệt, trong khi TCSEC [của Hoa Kỳ] gôm chúng lại với nhau và gán cho chúng cùng một Rating, không có sự tách biệt [Từ D đến A1].

Danh sách sau đây cho thấy các loại Functionalities và các hạng mục Assurance khác nhau được kiểm tra trong quá trình Evaluation :

• Security functional requirements • Identification and authentication • Audit • Resource utilization • Trusted paths/channels • User data protection • Security management • Product access • Communications • Privacy • Protection of the product’s security functions • Cryptographic support • Security assurance requirements • Guidance documents and manuals • Configuration management • Vulnerability assessment • Delivery and operation • Life-cycle support • Assurance maintenance • Development • Testing

Hãy xem xét lại ví dụ của chúng ta về 2 hệ thống mà có cùng một Functionality [liên quan đến các cơ chế bảo vệ] nhưng có Assurance Levels rất khác nhau. Sử dụng phương pháp tiếp cận TCSEC, sự khác biệt trong những Assurance Levels sẽ khó có thể phân biệt được, bởi vì Functionality và Assurance Level được Rated - Xếp hạng chung với nhau. Sử dụng phương pháp tiếp cận ITSEC, Functionality được Rated tách biệt với Assurance, cho nên sự khác biệt trong Assurance Levels sẽ dễ nhận biết hơn.

Trong ITSEC Criteria, Classes F1 đến F10 được dành để xếp hạng cho Functionality của các cơ chế bảo mật, trong khi E0 đến E6 được dành để xếp hạng cho Assurance của các cơ chế bảo mật.

Vì vậy, sự khác biệt giữa ITSEC và TCSEC chính là : TCSEC xếp hạng Functionality và Assurance cùng một Rate, trong khi đó ITSEC lại tách biệt 2 thuộc tính này, xếp hạng chúng riêng biệt. Còn có những sự khác biệt đó là ITSEC đã được phát triển để cung cấp một sự linh hoạt [flexibility] hơn TCSEC, và ITSEC giải quyết luôn cả 3 thuộc tính chính của Security [integrity, availablity, confidentiality], trong khi TCSEC chỉ giải quyết 1 thuộc tính duy nhất [confidentiality]. ITSEC còn giải quyết những hệ thống Networked [được nối mạng], trong khi TCSEC chỉ giải quyết Stand-alone Systems.

Table 5-2 là một bản Mapping chung cho 2 phương pháp Evaluation : ITSEC và TCSEC. Để cho chúng ta thấy được mối quan hệ của chúng với nhau.

Bạn có thể thấy, phần lớn Rating của ITSEC đều có thể ánh xạ đến Orange Book Ratings, nhưng sau đó ITSEC đã tiến xa hơn một bước và bổ sung thêm F6 đến F10 dành cho những nhu cầu cần thiết của người dùng mà Orange Book không đề cập đến.

ITSEC là một Criteria dành cho các Hệ Điều Hành và các sản phẩm, nó đề cập đến một cá thể như là một Target of Evaluation [TOE] - Mục Tiêu của cuộc Thẩm Định. Cho nên nếu bạn đang đọc tài liệu thảo luận về ITSEC Rating của một sản phẩm và nó tuyên bố TOE đã được Rating là F1 và E5, bạn có thể biết được TOE chính là sản phẩm đã được thẩm định và nó có Low Functionality Rating và High Assurance Rating.

Ratings liên quan đến Assurance, đó là Correctness - Tính chính xác và Effectiveness - Tính hiệu quả của cơ chế bảo vệ. Functionality được xem xét về mặt mục tiêu an ninh của hệ thống, các tính năng bảo mật và các cơ chế bảo mật. Sau đây là một số ví dụ về những Functionalities được xem xét kiểm tra : Identification & Authentication, Access Control, Accountability, Auditing, Object Reuse, Accuracy, Service Reliability và Data Exchange.

Common Criteria - Tiêu Chuẩn Chung "TCSEC quá khó, ITSEC quá mềm mỏng, nhưng Common Criteria thật sự phù hợp"

Orange Book và Rainbow Series cung cấp một chương trình Evaluation quá cứng nhắc cho thế giới Business. ITSEC cố gắng cung cấp một cách tiếp cận linh hoạt hơn bằng cách Separating - Tách biệt Functionality và Assurance. Tuy nhiên, sự linh hoạt này vô hình chung lại làm tăng thêm độ phức tạp bởi vì các thẩm định viên [evaluators] có thể trộn và kết hợp Functionality và Assurance Ratings, điều đó mang lại kết quả có quá nhiều Classifications cần phải duy trì.

Bởi vì chúng ta là nhân loại thông minh, không ngừng phát triển và cải tiến, nỗ lực để tìm kiếm ra một Evaluation Criteria hiệu quả hơn, đó chính là Common Criteria - Tiêu Chuẩn Chung.

Năm 1990, International Organization for Standardization [ISO] đã xác định cần phải có một International Standard Evaluation Criteria để sử dụng cho toàn cầu. Dự án Common Criteria bắt đầu vào năm 1993 khi một số tổ chức ngồi lại với nhau và căn chỉnh các Evaluation Criteria hiện có [TCSEC, ITSEC, Canadian Trusted Computer Product Evaluation Criteria [CTCPEC], Federal Criteria].

Common Criteria đã được phát triển thông qua sự hợp tác giữa các tổ chức National Security Standards trong phạm vi US, Canada, France, Germany, United Kingdom và Netherlands.

Lợi ích của việc có một tập hợp Criteria được công nhận và chấp nhận mang tính toàn cầu, có thể giúp cho người tiêu dùng rất nhiều bằng cách giảm bớt sự phức tạp của các Ratings và loại bỏ đi những định nghĩa và ý nghĩa cần phải hiểu của các Ratings khác nhau bên trong những chương trình Evaluation khác nhau. Điều này cũng giúp ích cho các nhà sản xuất, bởi vì giờ đây họ có thể xây dựng một tập hợp Requirements cụ thể nếu họ muốn bán sản phẩm của họ khắp toàn thế giới, thay vì phải đáp ứng một số Ratings khác nhau với những quy tắc và những đòi hỏi khác nhau.

Orange Book thẩm định tất cả các hệ thống bằng cách so sánh chúng với Bell-LaPadula Model. Common Criteria cung cấp tính linh hoạt nhiều hơn, bằng cách thẩm định một sản phẩm với một Protection Profile, nó được cấu trúc để giải quyết nhu cầu Security của thế giới thực [Real-World].

Vì vậy trong khi Orange Book phát biểu : "Tất cả mọi người phải theo hướng này, trong hình thức này, bằng cách sử dụng con đường này", thì Common Criteria lại đặt ra câu hỏi : "Okay, những mối đe dọa nào mà ngày nay chúng ta đang phải đối mặt và những cách tốt nhất nào để chiến đấu lại với chúng ?"

Theo mô hình Common Criterial, Evaluation được thực hiện trên một sản phẩm và nó sẽ được gán một Evaluation Assurance Level [EAL]. Việc thử nghiệm hết sức nghiêm ngặt và triệt để như là cách để gia tăng Assurance Levels. Common Criteria có 7 Assurance Levels. Phạm vi bắt đầu từ EAL1, nơi diễn ra việc kiểm tra Functionality, cho đến EAL7, nơi kiểm tra kỹ lưỡng được tiến hành và System Design được verified. Những gói EAL khác nhau được liệt kê sau đây :

• EAL1 Functionally tested • EAL2 Structurally tested • EAL3 Methodically tested and checked • EAL4 Methodically designed, tested, and reviewed • EAL5 Semiformally designed and tested • EAL6 Semiformally verified design and tested • EAL7 Formally verified design and tested

Chú ý : Khi một hệ thống "Formally Verified - Chính thức được xác nhận", điều đó có nghĩa là nó được dựa trên một mô hình mà có thể chứng minh toán học - Mathematically.

Common Criteria sử dụng Protection Profiles trong quá trình thẩm định. Đây là một cơ chế được sử dụng để mô tả nhu cầu về một sản phẩm trong thế giới thực, mà hiện nay chưa xuất hiện trên thị trường. Protection Profiles bao gồm một tập hợp Security Requirements, lý luận và ý nghĩa của chúng, EAL Rating tương ứng mà sản phẩm nhắm đến. Protection Profile mô tả những giả định về môi trường [environmental assumptions], những mục tiêu, Functional và Assurance Level mong đợi.

Mỗi Threat có liên quan được liệt kê cùng với cách nó sẽ được kiểm soát như thế nào bởi các mục tiêu cụ thể. Protection Profile cũng "biện minh - justifies" cho Assurance Level và Requirements về sức mạnh của mỗi cơ chế bảo vệ.

Protection Profile cung cấp những cách thức cho người tiêu dùng để xác định nhu cầu Security cụ thể, điều này là để "giải quyết rốt rẻn" một Security Problem nào đó. Nếu có một người nào đó xác định nhu cầu Security mà hiện tại không có bất kỳ sản phẩm nào có thể giải quyết được, người đó có thể viết ra một Protection Profile, mô tả sản phẩm đó sẽ là một giải pháp để giải quyết vấn đề này trong thế giới thực.

Protection Profile cung cấp những mục tiêu cần thiết và các cơ chế bảo vệ để đạt được mức độ Security cần thiết, cũng như một danh sách những sai lầm có thể mắc phải trong quá trình phát triển hệ thống. Danh sách này được sử dụng bởi các kỹ sư phát triển hệ thống, và sau đó được sử dụng bởi các thẩm định viên để đảm bảo các kỹ sư đã vượt qua tất cả những sai lầm có thể mắc phải này.

Protection Profiles đã được phát triển để mô tả Functionanlity, Assurance, Description và Rationale của Product Requirements.

Giống như các Evaluation Criteria trước đây, Common Criteria về cơ bản cũng làm việc để trả lời 2 câu hỏi về sản phẩm đang được thẩm định : Các cơ chế bảo mật của nó làm gì ? [Functionality] và làm thế nào để đảm bảo những thứ đó hoạt động ổn định ? [Assurance]. Hệ thống này thiết lập một Framework cho phép người tiêu dùng xác định rõ ràng Security issues và problems của họ; các nhà phát triển xác định Security Solution để giải quyết những Problems đó; Evaluators - các nhà thẩm định viên sẽ xác định rõ ràng xem những gì mà sản phẩm thực sự có thể hoàn thành.

Protection Profile bao gồm 5 phần sau đây :

• Descriptive Elements - Các yếu tố mô tả : Cung cấp tên của Profile và mô tả về Security Problem được giải quyết.

• Rationale - Lý do cơ bản : Chứng minh Profile và cung cấp một mô tả chi tiết hơn về Problem trong thế giới thực sẽ được giải quyết. Environment, Usage Assumptions - Những giả định về việc sử dụng, Threats được minh họa cùng với Guidance - Hướng dẫn về các Security Policies mà có thể được hỗ trợ bởi Products và Systems chiếu theo Profile này.

• Functional Requirements - Các yêu cầu chức năng : Thiết lập Protection Boundary - Vành Đai Bảo Vệ, có nghĩa là các Threats hoặc Compromises bên trong vành đai này sẽ bị chặn lại. Product hoặc System bắt buộc phải thực thi vành đai đã được thiết lập trong phần này.

• Development assurance requirements - Các yêu cầu đảm bảo trong quá trình phát triển : Xác định các yêu cầu cụ thể mà Product hoặc System bắt buộc phải đáp ứng trong giai đoạn Development, từ Design đến Implementation.

• Evaluation assurance requirements - Các yêu cầu đảm bảo trong quá trình thẩm định : Thiết lập loại và mức độ của cuộc Thẩm Định.

Evaluation Process chỉ là 1 phần trong việc xác định Functionality và Assurance của một Product. Sau khi Product đạt được một Rating cụ thể, thì Rating đó chỉ áp dụng cho một phiên bản cụ thể và những cấu hình đặc thù nào đó của sản phẩm mà thôi. Cho nên nếu có một công ty muốn mua một Firewall chỉ bởi vì Firewall đó có High Assurance Rating, công ty đó sẽ không còn được sự đảm bảo nào nữa nếu như phiên bản kế tiếp của Firewall Software không được thẩm định và được Rating.

Điều này cũng tương tự nếu như công ty mua Firewall và cài đặt nó với cấu hình Not Recommended, mức độ Security mà công ty hy vọng đạt được có thể sẽ không như ý. Vì tất cả những Ratings này đều là được thẩm định và xem xét trong phòng Lab. Khi Product được triển khai trong môi trường thực tế, những yếu khác hơn so với Rating của nó cần được giải quyết và được đánh giá, để đảm bảo nó có thể bảo vệ một cách chính xác nhất cho Resource và Environment.Chú ý : Khi một Product được gán một Assurance Rating, điều này có nghĩa nó đã có tiềm năng cung cấp mức độ bảo vệ này. Khách hàng đã có cấu hình thích hợp của Product để thực sự đạt được mức độ bảo vệ này. Vendor cần phải cung cấp Configuration Documentation cần thiết và giữ nó up-to-date cho khách hàng để cho họ có thể cấu hình sản phẩm luôn luôn chính xác.

Certification vs. Accreditation - Chứng nhận so với Công Nhận

Chúng ta đã đi qua rất nhiều loại Evaluation Critearia mà một hệ thống có thể được thẩm định để nhận một Rating cụ thể. Đây là một quá trình rất chính thống, sau khi hệ thống hoặc sản phẩm được Evaluated, chúng sẽ được đặt lên một EPL chỉ ra cho biết Rating mà chúng đạt được. Người tiêu dùng có thể kiểm tra danh sách này và so sánh các sản phẩm cũng như các hệ thống với nhau để biết được Rank của chúng trong việc bảo vệ thích hợp. Tuy nhiên, sau khi người tiêu dùng mua sản phẩm và đặt nó vào môi trường của họ, Security cũng chưa chắc được Guaranteed - Bảo đảm.

Security được tạo ra từ System Administration, Physical Security, Installation và Configuration Mechanisms bên trong môi trường và những vấn đề Security khác. Nói một cách công bằng để hệ thống đạt được sự àn toàn, tất cả những hạng mục vừa nói qua cần phải được tính đến. Rating chỉ là một mẩu bánh nhỏ trong chiếc bánh Security Pizza to mà thôi.

Certification - Chứng nhận

Certification là Comprehensive Technical Evaluation - Việc thẩm định kỹ thuật toàn diện các Security Components và tính tuân thủ [compliance] của chúng dành cho mục đích Accreditation - Công Nhận. Certification Process - Quy trình cấp chứng nhận có thể sử dụng Safeguard Evaluation, Risk Analysis, Verification, Testing và Auditing Techniques để đánh giá sự phù hợp của một hệ thống cụ thể.

Ví dụ, giả sử Tí là một chuyên gia bảo mật trong một công ty, mà công ty này chỉ mua các hệ thống mới được sử dụng để xử lý dữ liệu bí mật của họ. Tí muốn biết những hệ thống này có phù hợp cho các công việc xử lý dữ liệu bí mật hay không, và chúng có cung cấp mức độ bảo vệ cần thiết hay không. Tí cũng muốn chắc chắn rằng chúng có thể tương thích với môi trường hiện tại, không làm giảm hiệu suất và không mở ra những "cánh cửa" mới cho các Threats mới.

Về cơ bản, Tí muốn biết xem những sản phẩm này có phù hợp cho công ty của anh ta hay không. Tí có thể trả phí cho một công ty chuyên về những vấn đề này để thực hiện các Procedures cần thiết, nhằm Certify các hệ thống hoặc nó có thể được thực hiện trong nội bộ. Evaluation Team - Đội ngũ thẩm định sẽ thực hiện các cuộc kiểm tra về Software Configurations, Hardware, Firmware, Design, Implementation, System Procedures và Physical & Communications Controls.

Mục tiêu của Certification Process là để đảm bảo một System, một Product hoặc một Network sẽ phù hợp với các mục đích của khách hàng. Các khách hàng sẽ trông cậy vào một Product vì nhiều lý do khác nhau, các môi trường sẽ có những mức độ Threat khác nhau. Vì vậy cho nên một Product nào đó không nhất thiết phải phù hợp tốt nhất [best fit] cho tất cả các khách hàng hiện có. [Tất nhiên, các nhà cung cấp sẽ cố gắng thuyết phục bạn.]

Product cung cấp đúng Functionality và Security cho khách hàng, chính là toàn bộ mục đích của Certification Process.

Certification Process và các tài liệu tương ứng sẽ chỉ ra cho biết Tốt, Xấu về Product và chỉ ra cho biết cách hoạt động của nó bên trong một môi trường nhất định. Dan sẽ đem những kết quả này và trình chúng lên Management của anh ta dành cho Accreditation Process - Quá Trình Công Nhận.

Accreditation - Công nhận

Accreditation là một sự Formal Acceptance - Chấp Nhận Chính Thức về tổng thể Security và Functionality của hệ thống bởi Management. Certification Information được trình bày đến Management hoặc cơ quan chịu trách nhiệm, để Management có thể đặt câu hỏi, xem xét Reports và ra quyết định xem có nên chấp nhận một Product cụ thể nào đó hay không, cũng như xem liệu có bất kỳ hành động khắc phục [corrective] nào cần phải diễn ra hay không.

Sau khi Management đã hài lòng với tổng thể an ninh của hệ thống đã được trình bày, Management sẽ đưa ra một Formal Accreditation Statement - Tuyên Bố Công Nhận Chính Thức. Bằng cách này, Management sẽ nêu rõ sự hiểu biết của anh ta về mức độ bảo vệ mà hệ thống sẽ cung cấp trong môi trường hiện tại, cũng như sự hiểu biết của Management về những rủi ro bảo mật gắn liền với việc cài đặt và bảo trì hệ thống này.

No More Pencil Whipping - Đừng đảo bút ký nhầm anh "Quản Lý" ơi !

Nhiều tổ chức đang làm cho Accreditation Process trở nên nghiêm trọng hơn so với những gì họ đã làm trong quá khứ. Thật không may, đôi khi Certification Process đã hoàn tất, Documentation đã gửi đến để cho Management review và approval, Management chỉ ký một cách mù quáng mà không thực sự hiểu rõ về những gì họ đang ký !

Accreditation - Sự Công nhận, có nghĩa là Management accepting - đang chấp nhận những rủi ro đi kèm có liên quan đến Product mới được đưa vào trong môi trường của tổ chức. Khi một sự thỏa hiệp an ninh rộng lớn diễn ra, mọi trách nhiệm sẽ đổ dồn về phía người đã đặt bút ký duyệt đưa sản phẩm này vào sử dụng. Cho nên, Management cần phải có trách nhiệm hơn với những gì họ đặt bút xuống ký ! Hành vi Ký "bừa" lên Accreditation Papers đang giảm dần nhưng không có nghĩa là nó đã dừng hẳn lại đâu.Chú ý : Certification là một cuộc Technical Review - Đánh Giá Kỹ Thuật, đánh giá các cơ chế an ninh và thẩm định tính hiệu quả của chúng. Accreditation là một sự chấp nhận chính thức của Management về kết quả đã thu nhận được từ Certification Process.

Bởi vì Software, System và Environments không ngừng thay đổi và phát triển theo thời gian, cho nên Certification và Accreditation cũng cần phải liên tục diễn ra không ngừng nghỉ. Bất kỳ sự bổ sung thêm Software, thay đổi hệ thống hoặc sửa đổi môi trường nào cũng cần phải bắt đầu một Certification và Accreditation Cycle mới.

Open vs. Closed Systems - Hệ thống Mở so với Hệ thống Khép Kín

Hệ thống máy tính có thể được phát triển để dễ dàng tích hợp với những hệ thống và những sản phẩm khác [Open Systems] hoặc có thể được phát triển chỉ để làm việc "độc quyền" với một Subset - Tập hợp con duy nhất các hệ thống và các sản phẩm [Closed systems]. Những phần sau đây sẽ mô tả sự khác biệt giữa các phương pháp tiếp cận.

Open Systems

Open System được xây dựng dựa trên Standards, Protocols, và Interfaces đã được công bố Specifications, cho phép các bên thứ 3 phát triển thêm Add-on Components và Devices. Đây là loại kiến trúc cung cấp Interoperability - Khả năng tương thích giữa các Products được tạo ra bởi những Vendors khác nhau. Khả năng tương tác được cung cấp bởi tất cả các Vendors có liên quan, những người tuân thủ theo các Standards cụ thể và cung cấp các Interfaces mà cho phép mỗi hệ thống có thể dễ dàng giao tiếp với các hệ thống khác và cho phép các Add-ons để Hook vào bên trong hệ thống một cách dễ dàng.

Phần lớn các hệ thống ngày nay đều là Open Systems. Lý do mà một Administrator có các máy tính Windows XP, Windows 7, Macintosh và Unix dễ dàng tương tác với nhau trên cùng một Network là bởi vì chúng là những nền tảng Open - Mở. Nếu có một nhà cung cấp tạo ra Closed System, họ sẽ hạn chế doanh số bán hàng tiềm năng của mình với một môi trường độc quyền. Ví dụ, chỉ dành cho Government hoặc Military.Chú ý : Trong Domain Application Security, chúng ta sẽ xem xét các Standards mà hỗ trợ khả năng tương tác [interoperability], bao gồm CORBA, DCOM, J2EE và còn nhiều thứ nữa.

Closed Systems - Hệ Thống Khép Kín [hay còn có thể gọi là Hệ Thống Đóng]

Closed System - Hệ thống khép kín sử dụng Architecture mà không tuân theo một Industry Standards - Tiêu Chuẩn Công Nghiệp nào cả. Khả năng tương thích và các Standard Interfaces KHÔNG được sử dụng để có thể dễ dàng cho việc giao tiếp giữa các loại hệ thống khác nhau và các tính năng Add-on. Closed System là Proprietary - Độc Quyền, có nghĩa là hệ thống chỉ có thể giao tiếp với các hệ thống tương tự nó.

Closed Architecture - Kiến trúc khép kín cung cấp độ bảo mật nhiều hơn cho hệ thống, bởi vì nó không có nhiều cánh cổng đi vào trong, nó hoạt động trong một môi trường như "tu sĩ ẩn dật" chứ không như các môi trường "Mở". Bởi vì Closed System là độc quyền, cho nên không có nhiều công cụ Thwart - Gây trở ngại cho các cơ chế an ninh của nó, không có nhiều người biết đến Design, Language và các Security Weaknesses của nó để khai thác nó.

Phần lớn các hệ thống ngày này đều được xây dựng với Open Architecture - Kiến Trúc Mở, cho phép chúng bắt tay làm việc với những hệ thống khác, có thể dễ dàng chia sẻ thông tin và tận dụng lợi thế của những Functionality mà bên thứ 3 mang lại. Tuy nhiên, điều này mở ra nhiều cánh cửa đến với Hacks, Cracks và Attacks.

Enterprise Architecture

Cho đến bây giờ chúng ta được truyền thụ qua khá nhiều tuyệt kỹ liên quan đến rất nhiều Hệ Điều Hành, Applications và các Concepts. Chúng ta đã bắt với Architecture of System - Kiến trúc của một hệ thống, đã đi xuyên qua rất nhiều thành phần mà bắt buộc phải được xây dựng một cách an toàn để đảm bảo mức độ bảo vệ cần thiết được đòi hỏi từ chúng.

System Security Architecture - Kiến Trúc An Ninh Hệ Thống là một thiết kế High-Level mà hoạt động như một Framework. Architecture đưa ra những điều cần phải được thực hiện để đảm bảo Security Policy của hệ thống và Protection Level được đáp ứng. Quá tuyệt vời khi nắm được những kiến thức này, vậy Enterprise Security Architecture là gì ?

Các tổ chức có đều có những sự chọn lựa khi mong muốn đảm bảo an toàn cho môi trường của họ như một tổng thể.

Option 1 : Họ có thể chỉ quăng hoặc bốc đại ra một vài giải pháp ABCD nào đó, chúng còn được gọi là Point Solutions hoặc Stovepipe Solutions, họ hy vọng cách tiếp cận "đặc biệt kỳ diệu" này có thể hoạt động theo cách thức đảm bảo an toàn cho môi trường tổng thể, bao gồm mọi Vulnerabilities của doanh nghiệp.

Option 2 : Hoặc họ có thể dành thời gian để tìm hiểu về Environment, hiểu về những yêu cầu Security của Business và Environment, đưa ra một Overarching Framework - Nền tảng bao quát và Strategy, sau đó ánh xạ chúng lại với nhau.

Đa phần các tổ chức thường chọn Option 1 [bốc thuốc đại], đó là "Constantly Putting Out Fires" Approach - Phương pháp liên tục châm lửa. Đây là cách thức vô cùng đáng yêu giúp gia tăng mức độ Stress, các yêu cầu Security không được đáp ứng, khiến cho sự nhầm lẫn và hỗn loạn được dịp tung hoành thoải mái.

Cách tiếp cận theo Option 2 là để xác định một Enterprise Security Achitecture, cho phép nó hướng dẫn khi triển khai các Solutions để đảm bảo đáp ứng được các nhu cầu, cung cấp Standard Protection khắp toàn môi trường, và giảm thiểu số lượng Security Surprises - Những "bất ngờ" An Ninh mà tổ chức có thể sẽ gặp phải.

Mặc dù triển khai Enterprise Security Architecture không nhất thiết đem lại một lời hứa xa vời nào cả, nhưng nó có thể chế ngự sự hỗn loạn trong tâm chí, giúp cho các nhân viên an ninh và tổ chức có một tư duy chủ động và trưởng thành hơn khi đối với các vấn đề Security như một tổng thể.

Enterprise Security Architecture xác định Information Security Strategy - Chiến Lược An Toàn Thông Tin mà bao gồm các Layers of Policy, Standards, Solutions, Procedures và cách chúng được liên kết lại với nhau xuyên qua Enterprise Strategically, Tactically và Operationally. Đây là một sự khác biệt so với Infrastructure Architecture. Infrastructure - Cơ sở hạ tầng về cơ bản là nói đến Technology và Hardware cần thiết để hỗ trợ cho Enterprise Security Architecture.

Vì vậy về cơ bản bạn có thể có một Infrastructure [switches, cables, routers, nodes, vân vân], nhưng nó đòi hỏi Software, Con Người và các Processes làm việc cùng nhau theo một cách gắn kết và an toàn để có một Enterprise Architecture thực sự. Bên cạnh Security, loại hình Architecture này còn cho phép tổ chức có thể đạt được Interoperability - Khả năng tương thích, Integraton - Tích hợp, Ease-of-use - Dễ dàng sử dụng, Standardization - Tiêu chuẩn hóa và Governance - Quản trị tốt hơn.

Làm thế nào để chúng ta biết được tổ chức của chúng ta vẫn chưa có một Enterprise Security Architecture ? Nếu hầu hết các câu hỏi sau đây bạn đều trả lời là "YES", thì có nghĩa Enterprise Security Architecture chưa được triển khai trong doanh nghiệp của bạn :

• Việc xác định Vulnerabilities và tổn thất của tổ chức mất hơn 15 ngày ?

• Khi yêu cầu truy cập của người dùng tăng lên do sự phát triển của doanh nghiệp, Security hoặc Network Administrator chỉ việc thay đổi Access Controls mà không cần Management của người dùng Approval ?

• Khi có một Product mới được triển khai, có những vấn đề về khả tương tác không lường trước được xuất hiện, yêu cầu thêm nhiều thời gian và tiền bạc để sửa chữa ?

• "Làm 1 lần cho xong rồi thôi" thay vì tuân thủ theo Standardized Procedures khi những vấn đề Security phát sinh ?

• Business Unit Managers trong tổ chức không nhận thức được trách nhiệm của họ về Security và cách ánh xạ trách nhiệm của họ đến vấn đề pháp lý và các yêu cầu của pháp luật ?

• "Sensitive Data - Dữ Liệu Nhạy Cảm" được định nghĩa trong Policy, nhưng các Controls cần thiết không được triển khai đầy đủ và không được giám sát ?

• Stovepipe [Point] Solutions được triển khai thay vì Enterprise-wide Solutions ?

• Có những sai lầm "đắt giá" không ngừng diễn ra ?

• Có một sự ngắt quãng liên tục trong quan hệ giữa Mangement và nhân viên Security ?

• Security Governance - Quản trị an ninh hiện tại không có, bởi vì doanh nghiệp không được theo dõi hoặc giám sát theo cách tiêu chuẩn hóa và toàn diện ?

• Có các Business Decisions - Quyết Định Kinh Doanh nào mà không đề cập đến Security hay không ?

• Nhân viên Security trong tổ chức thường chuyên đi "chữa cháy" là chính chứ không có thời gian để xem xét và pháp triển các phương pháp tiếp cận mang tính chiến lược ?

• Các chuyên gia bảo mật trong tổ chức có thường phải dùng đến thuốc chống trầm cảm và chống nhức đầu, chống lo âu ?

Nếu đa số các câu trả lời trên đây là "Yes", thì có nghĩa trong tổ chức của chúng ta vẫn chưa có một Architecture hữu ích tồn tại. Sau đây là một số những điều hết sức thú vị, mà tác giả đã quan sát được trong nhiều năm làm việc. Hầu hết các tổ chức đều mắc phải những Problems đã liệt kê ở trên, nhưng họ chỉ tập trung vào những vấn đề này nếu như họ đã Unconnected.

CSO, CISO hoặc Security Administrator không hiểu rằng đây là những triệu chứng [symptoms] của một căn bệnh có thể điều trị được. "Treatment - Điều trị" bằng cách thành lập một nhóm chuyên gia lo phụ trách về Security, có Leader, có sự hỗ trợ của Management, chịu trách nhiệm phát triển Enterprise Security Architecture theo từng giai đoạn đã lên kế hoạch.

Mục tiêu là để chuyển đội từ Technology-Oriented sang Business-Centric security processes; liên kết Administrative, Technical và Physical Controls đến Manage Risk thích hợp; và tích hợp những Processes này vào trong IT Infrastructure, Business Processes và Organization Culture - Văn hóa tổ chức.

Lý do chính mà các tổ chức không phát triển và đưa ra một Enterprise Security Architecture là bởi vì họ không hiểu trọn về kiến trúc đó và có vẻ như nó là một công việc quá sức. Chữa cháy, lủng đâu vá đó thường dễ hiểu và dễ làm hơn, cho nên nhiều tổ chức chọn lựa sống chung với phương pháp tiếp cận này.

Nếu các bạn còn nhớ, trong Domain : Information Security & Risk Management, chúng ta đã đề cập đến việc Làm Thế Nào Để Thiết Lập một Security Program, các công việc sau đây đã được vạch ra :

1. Plan & Organize : Lên kế hoạch và tổ chức

* Thiết lập một cam kết quản lý * Thành lập ban chỉ đạo giám sát * Đánh giá các nhu cầu kinh doanh * Thực hiện một hồ sơ thu thập các mối đe dọa đối với tổ chức * Thực hiện đánh giá rủi ro * Xây dựng kiến trúc an ninh theo tổ chức, theo sự ứng dụng, theo mạng lưới điện toán và theo các cấp độ của từng thành phần * Xác định các giải pháp cho mỗi cấp độ kiến trúc * Xin quản lý phê duyệt để tiếp tục tiến hành giai đoạn tiếp theo.

2. Implement : Triển khai thực hiện

* Phân công vai trò và trách nhiệm * Xây dựng và phát triển security policies, procedures, standards, baselines, guidelines. * Xác định dữ liệu nhạy cảm khi trung chuyển [in transit] và dữ liệu thanh lý [at rest : dữ liệu không còn sử dụng nữa, nằm trong các phương tiện lưu trữ chờ thanh lý] * Triển khai thực hiện các đồ án [blueprints] sau đây : o Xác định và quản lý tài sản o Quản lý rủi ro o Quản lý Vulnerability [lỗ hổng an ninh dễ tổn thương] o Quản lý việc tuân thủ chính sách o Xác định quản lý và kiểm soát truy cập o Kiểm soát thay đổi o Lifecycle phát triển phần mềm o Lập kế hoạch kinh doanh liên tục không gián đoạn [business continuity] o Nâng cao nhận thức và đào tạo o An ninh vật lý o Phản hồi sự cố [Incident response] * Triển khai các giải pháp [administrative, technical, physical] cho từng đồ án. * Xây dựng cơ chế kiểm toán và giám sát các giải pháp cho từng đồ án. * Thiết lập mục tiêu, các thỏa thuận cấp độ dịch vụ [SLAs], và các số liệu cho từng đồ án.

3. Operate and maintain : Vận hành và bảo trì

* Thực hiện theo các procedures [thủ tục] đã đề ra để đảm bảo tất cả các baselines [thông số chuẩn] đều được đáp ứng khi triển khai từng đồ án. * Thực hiện kiểm toán internal và external. * Thực hiện các công việc đã đề ra trong từng đồ án * Quản lý thỏa thuận mức độ dịch vụ SLA trong từng đồ án

4. Monitor and evaluate : Giám sát và đánh giá

* Xem lại logs, kết quả kiểm toán, thu thập số liệu giá trị và SLAs của từng đồ án * Thẩm định các mục tiêu thành tích của từng đồ án * Thực hiện các cuộc họp báo cáo hàng với quý với ban chỉ đạo * Phát triển các bước cải tiến và tích hợp vào giai đoạn Plan & Organize

[Tham khảo trong Domain Information Security & Risk Management Phần II trên Website của DNA]

Đây là cũng là những bước cơ bản của việc thiết lập một Enterprise Security Architecture, bởi vì Security Program và Security Architecture bắt buộc phải tuân theo cùng một Model. Security Program thường được xem là Administrative Components - Các thành phần hành chính, chẳng hạn như Policies, Standards, Risk Management, Personnel Security, Data Classification, vân vân. Về cơ bản, tất cả các khái niệm chính đã được đề cập trong Domain IS&RM đều là một thành phần của Security Program.

Enterprise Security Architecture đi sâu hơn so với Security Program và cung cấp mức độ chi tiết hơn. Ví dụ, nếu Security Policy ra lệnh rằng Network Access Control bắt buộc phải được triển khai và được thực thi, Architecture sẽ bao gồm : Network Schematic - Sơ đồ mạng, Network Zones dựa trên Trust Level và Business Needs, External Connections, Security Mechanisms, Tools, Processes và các Roles liên quan tại mỗi Level. Architecture hoạt động theo cách của nó xuống từ Policy Level cho đến Component Level.

Tương tự, giả sử Shannel nói với người thợ xây dựng rằng cô ta muốn có một ngôi nhà theo kiểu trang trại, với bốn phòng ngủ, có kích thước 2,500 feet vuông. Đây là một sự mô tả High-level [Policy]. Anh thợ xây sẽ sử dụng một Blueprint - Bản thiết kế để mà làm theo [Architecture], nó sẽ cung cấp các yêu cầu chi tiết hơn phải đáp ứng được những yêu cầu của Shannel.

Hầu như tất cả các Enterprise Security Architectures vững chắc đều hoạt động với Structure được cung cấp bởi Zachman Architecture Framework bằng cách này hoặc cách khác. Table 5-3 cho chúng ta thấy những thứ tạo nên Architectural Framework này. [Để xem trọn vẹn Framwork, hãy truy cập vào www.zifa.com].

Zachman Framework đã xuất hiện từ nhiều năm nay và được sử dụng bởi nhiều tổ chức với mục đích xây dựng hoặc xác định tốt hơn cho môi trường Business của họ. Framework này không phải Security-oriented - Theo định hướng Bảo Mật, nhưng nó là một Template tốt để làm việc với nó, bởi vì nó cung cấp định hướng cho chúng ta có thể hiểu được cách doanh nghiệp thực sự trong một Modular.Chú ý : Zachman Framework được sử dụng như một Model dành cho các Security Architectures vững chắc, có nghĩa là nó giải quyết nhiều loại thành phần bên trong tổ chức. Nhiều người chủ yếu đã quen thuộc với các Technical Security Architecures, mà chúng chỉ giải quyết với Network hoặc các hệ thống bên trong Network. Đây là hai thứ hoàn toàn khác nhau. Robust Security Architecture bao gồm Technical Architecture và nhiều thứ hơn nữa, bạn có thể tham khảo Table 5-3.

Zachman Framework là Two-Dimensional Model - Mô hình 2 chiều, sử dụng 6 câu hỏi giao tiếp cơ bản [What, How, Where, Who, When, Why], giao cắt với các mức độ khác nhau [Planner, Owner, Designer, Builder, Implementer, Worker] để cung cấp một cái nhìn tổng thể cho doanh nghiệp. Framework này đã được phát triển trong những năm 1980s và được dựa trên các nguyên tắc của Business Architecture cổ điển.

Dựa trên kinh nghiệm của tác giả, hầu hết các "chuyên gia kỹ thuật" đều có một phản ứng tiêu cực đối với các Models này. Họ cảm thấy nó quá nhiều công việc, đó là một đám rối nùi, không có liên quan gì cả, vân vân. Nếu bạn đưa cho họ một sơ đồ mạng với Firewalls, IDSs, và VPNs, họ sẽ nói "Đây, đây mới là Security nè!". Điều này là bởi vì họ tập trung chủ yếu vào Technology, họ không hiểu hết được tất cả các thành phần khác của Security, cũng giống như Technology, đôi khi còn quan trọng hơn nữa.

Làm việc ở cấp độ Enterprise đòi hỏi phải có sự tư duy khác biệt so với làm việc ở System hoặc cấp độ Technical. Không chỉ áp dụng các giải pháp cho toàn bộ doanh nghiệp theo một cách tiêu chuẩn hóa, mà họ còn cần phải vẽ Map đến những nhu cầu Business. Ví dụ, khi suy nghĩ về Access Control—thay vì chỉ nghĩ đến Kerbeos, Domain Controllers, ACLs và Credentials—chúng ta còn bắt buộc phải xem xét đến những quy định và luật pháp hiện hành mà công ty bắt buộc phải tuân thủ.

Ví dụ, nếu công ty bắt buộc phải tuân thủ theo Đạo Luật Sarbanes-Oxley [SOX], công ty sẽ cần các Processes này được Documented và việc Access bắt buộc phải được approved bởi Managers. Điều này có thể đòi hỏi Identity Management Solutions thay vì chỉ phụ thuộc vào công nghệ Domain Authentication của Microsoft.

Khi Enterprise Security Architecture đang được phát triển, các hạng mục sau đây bắt buộc phải được hiểu rõ và được tuân theo : Strategic Alignment - Định Hướng Chiến Lược, Process Enhancement - Cải Tiến Quá Trình, Business Enablement và Security Effectiveness - Hiệu Quả Bảo Mật.

Strategic Alignment - Định Hướng Chiến Lược có nghĩa là các động cơ kinh doanh và các yêu cầu pháp lý đang được đáp ứng bởi Security Architecture. Security Posture - "Thế trận" an ninh hiện tại cần phải được hiểu rõ. Điều này có nghĩa là Enterprise Risk Assessment đã được thực hiện để tổ chức có thể hiểu được các Threats hiện tại và khả năng của họ trong việc đối phó với các Threats này. Nên có một sự nhất trí về các Vulnerabilities và các Threats bên trong tổ chức. Nó cũng có nghĩa là một Acceptable Risk Level đã được thiết lập dựa trên Risk Tolerance của tổ chức.

Tuyệt vời, vậy Strategic Aligment có nghĩa là gì ? Nó có nghĩa là "Những tài sản nào chúng ta có thể bảo vệ ?", "Làm thế nào để các sáng kiến Security của chúng ta gắn liền với nhu cầu kinh doanh ?", "Định nghĩa của 'bảo mật đầy đủ' là gì ?" và "Quản lý cấp cao có biết và hỗ trợ tất cả những điều này hay không ?"

Kết quả của những sự nỗ lực này là để đưa ra một Agreed-upon Current Risk Profile - Hồ sơ Rủi Ro hiện tại đã được chấp thuận và Desired Profile. Một kế hoạch Security Plan trong thời gian 3 năm nên được phát triển, vạch ra cách tổ chức sẽ nhận và sẽ đạt được, desired profile - hồ sơ mong muốn và cũng nên chi tiết phương pháp tiếp cận theo từng giai đoạn [phased approach] có liên quan đến Security Enterprise sẽ được xây dựng như thế nào.

Chú ý : Thông tin trên có vẻ rất rõ ràng những gì cần phải diễn ra đầu tiên, nhưng tiếc là nhiều công ty ngay lúc bắt đầu chỉ chăm chăm vào Firewalls, configuring ACLs, và đưa ra các giải pháp Encryption mà không thiết lập một kế hoạch tổng thể. Nó làm cho tất cả mọi người trông có vẻ bận rộn, nhưng thực ra họ lại đi đến những con đường khác nhau mà không có một mục tiêu chung đã được thỏa thuận để tất cả mọi người cùng hướng đến.

Một vài hạng mục khác được tiếp cận đến trong giai đoạn Strategic :

• Skateholders - Các bên có liên quan và những yêu cầu của họ được xác định • Owners và Custodian được xác định và được phân công trách nhiệm. • Responsibility, Accountability và Authority được xác định và được giao. • Một người nào đó sẽ mang một kết bia đến để được thông qua hết tất cả các giai đoạn còn lại.

Senior Management bắt buộc phải tích cực tham gia ở giai đoạn này và cung cấp các tài nguyên cũng như sự hỗ trợ cần thiết. Nếu không có sự hỗ trợ của Management, các nỗ lực sẽ hết sức khập khiễn, không đạt được sự thành công thực sự.

Khi nhìn vào phần Business Enablement của Architecture, chúng ta cần phải tự nhắc nhở mình rằng các công ty kinh doanh là để kiếm tiền. Các công ty và các tổ chức không tồn tại chỉ vì một mục đích duy nhất là Secure. Security không thể đại diện cho các quá trình Business, nhưng nó cần được triển khai để giúp cho các quá trình Business trở nên tốt hơn. Rất nhiều trong số các Critical Business Processes thường giải quyết end-to-end transaction integrity và integity thường là sự tập trung lớn nhất của các hoạt động Business.

Business enablement có nghĩa là các Core Business Processes được tích hợp vào bên trong Security Operating Model—chúng dựa trên các Standards và tuân theo Risk Tolerance-based Criteria. Điều này có ý nghĩa gì trong thế giới thực ? Giả sử rằng các giám đốc tài chính của tổ chức đã tìm ra được cách tiết kiếm tối ưu chi phí hoạt động nếu họ cho phép nhân viên Customer Service và Support làm việc từ nhà, công ty sẽ tiết kiệm được rất nhiều tiền, tiền thuê văn phòng, tiện ích, điện nước, bảo hiểm của họ sẽ rẻ hơn. Vậy cho nên công ty có thể chuyển sang mô hình hoạt động mới này bằng cách sử dụng VPN, Firewalls, Content Filtering, vân vân.

Nếu một tổ chức tài chính muốn cho phép khách hàng của họ có khả năng xem xét thông tin Bank Account và thực hiện việc chuyển tiền, họ có thể cung cấp dịch vụ này nếu như các cơ chế bảo mật chính xác đã được triển khai. Security cần giúp cho tổ chức phát triển mạnh mẽ bằng cách cung cấp các cơ chế để thực hiện những điều mới mẽ một cách an toàn.

Process Enhancement hoàn toàn có thể là một lợi ích dành cho tổ chức, nếu như họ biết tận dụng khả năng này. Khi một tổ chức có tinh thần nghiêm túc về việc đảm bảo an toàn cho môi trường của họ, nó có nghĩa là họ sẽ phải có một cái nhìn chặt chẽ hơn tại nhiều Business Processes mà sẽ diễn ra như một Ongoing Process - Quá Trình Liên Tục. Rất nhiều lần các Processes này được nhìn qua lăng kính của Security, bởi vì đó là lý do dành cho hoạt động này, nhưng đây là một cơ hội hoàn hảo để tăng cường và cải tiến các Processes tương tự nhằm tăng hiệu suất.

Khi bạn nhìn vào những Business Processes diễn ra trong tất cả các loại của các tổ chức, bạn thường sẽ tìm thấy một nhân bản của những sự nỗ lực, Manual Steps - các bước thủ công mà có thể dễ dàng được tự động hóa, hoặc cách sắp xếp và giảm tải thời gian, nỗ lực liên quan đến một công việc nhất định nào đó. Điều này thường được gọi là Process Reengineering - Tái Cấu Trúc Quá Trình.

Khi tổ chức đang phát triển Security Blueprints của họ, những Blueprints này bắt buộc phải được tích hợp vào bên trong Business Processes để có sự hiệu quả. Điều này có thể cho phép Process Management được cải tiến [refined] và được hiệu chuẩn hóa [calibrated]. Điều này có thể cho phép Security được tích hợp vào bên trong System Life Cycles và Day-to-day Operations.

Security Effectiveness - Hiệu quả Bảo Mật đề cập đến các Metrics - Số liệu, đáp ứng các yêu cầu Service Level Agreement [SLA], Return on Investment [ROI] - Lợi tức đầu tư, đáp ứng các Baselines và cung cấp việc quản trị với Dashboard hoặc Balanced Scorecard System. Đây là những cách để xác định các giải pháp Security và Architecture đang được triển khai hiện tại hữu ích như thế nào.

Nhiều tổ chức chỉ cần nhận được điểm này trong Architecture của họ, bởi vì họ có nhu cầu để đảm bảo rằng các Countermeasures được triển khai có thể cung cấp mức độ bảo vệ cần thiết và tiền của họ bỏ ra được sử dụng đích đáng. Sau khi Baselines được thiết lập, các Metrics có thể được phát triển để xác minh việc tuân thủ Baseline.

Các Metrics này sau đó được quản lý trong một Format mà họ có thể hiểu được, nó có thể cho họ thấy Health - Tình trạng sức khỏe của Thế Trận An Ninh [security posture] trong tổ chức và các mức độ tuân thủ. Điều này cũng cho phép Management nắm bắt được tình hình và đưa ra các quyết định kinh doanh thiết yếu.

Vấn đề bảo mật ảnh hưởng hầu như đến tất cả mọi người trong Business, cho nên thông tin này cần luôn Available để Senior Management có thể nắm bắt được khi họ thực sự cần sử dụng đến nó. Tất cả những hạng mục này : Strategic Alignment, Process Enhancement, Business Enablement, Security Effectiveness ... chỉ có thể diễn ra nếu có một nền tảng vững chắc với sự hỗ trợ của các Security Blueprints.

Blueprints phát thảo ra các cơ chế bảo mật thực tế sẽ được sử dụng để cung cấp cho tổ chức mức độ bảo vệ cần thiết. Những Blueprints có thể được triển khai bao gồm : Access Control, Identity Management, Asset Management, Incident Response, Infrastructure Security, Application Security và vân vân. Nếu không có một nền tảng hỗ trợ bảo mật vững chắc và hiệu quả, không có bất kỳ mục tiêu nào có thể thực sự được hoàn thành. Nó sẽ giống như việc chúng ta cố gắng xây dựng một ngôi nhà trên cát.

Figure 5-20 cho thấy cách các tổ chức thường tiến hóa trong sự trưởng thành Security của họ.

Chú ý : Enterprise Security Foundation - Nền Tảng Bảo Mật Doanh Nghiệp không thể nào được xây dựng mà không có các Security Zones được thiết lập. Điều này cung cấp các Boundaries - Ranh giới dựa trên Trust và xác định những gì thực sự cần được bảo vệ. Điều này sẽ cho phép việc bảo vệ và quản lý rủi ro được thực hiện trong một cách tiêu chuẩn hóa xuyên suốt toàn doanh nghiệp.

A Few Threats to Review - Xem xét lại một vài Mối Đe Dọa

Bây giờ chúng ta hãy xem nhanh qua một số điều mà có thể dẫn đến sai lầm khi thiết kế hệ thống nhé.

Software hầu như luôn luôn có Bugs và Vulnerabilities. Chức năng phong phú theo yêu cầu của người dùng sẽ mang lại nhiều sự phức tạp sâu xa, mà điều đó thường mở ra những cánh cổng đến các Problems trong thế giới máy tính. Ngoài ra, Vulnerabilities cũng luôn luôn ở xung quanh, bởi vì những kẻ tấn công không ngừng tìm kiếm cách phá hoại các hệ thống và sử dụng chúng một cách hết sức tiêu cực.

Cũng giống như sẽ luôn luôn tồn tại Cảnh Sát & Ăn Cướp, sẽ luôn luôn có Attackers & Security Professionals. Đây là một trò chơi xem ai khôn hơn ai, những người sẽ đặt ra mọi sự nỗ lực để dành lấy chiến thắng trong trò chơi này.

Maintenance Hooks

Trong thế giới lập trình, Maintenance Hooks là một loại Backdoor. Chúng là những Instructions bên trong Software mà chỉ có nhà phát triển biết được và có thể gọi được đến chúng, điều đó giúp cho các nhà phát triển có thể dễ dàng truy cập đến Code. Chúng cho phép các nhà phát triển xem và chỉnh sửa Code mà không cần phải đi xuyên qua các Access Controls thông thường.

Trong giai đoạn phát triển Software, chúng có thể rất hữu ích, nhưng nếu chúng không xóa bỏ trước khi Software đi vào sản xuất, chúng có thể gây ra nhất nhiều vấn đề ảnh hưởng đến Security vô cùng to lớn.

Maintenance Hooks thường khởi đầu bởi một Random Sequence - Chuỗi ngẫu nhiên Keystrokes, cung cấp việc truy cập vào bên trong Software mà không cần phải thông qua các Access Control và các Security Checks thông thường.

Application mà đã có Maintenance Hook, giúp cho các nhà phát triển có thể thực thi Commands bằng cách sử dụng một Specific Sequence - Chuỗi Keystrokes cụ thể. Sau khi điều này được thực hiện thành công, các nhà phát triển có thể ở bên trong Application [Inside], xem xét trực tiếp Code hoặc các Configuration Files. Nhà phát triển có thể thực hiện điều này để xem xét các Problems bên trong Code, kiểm tra Variable Population, Export thêm Code vào trong chương trình hoặc Fix Problems mà anh ta thấy đang diễn ra.

Mặc dù điều này nghe có vẻ tốt đẹp và lành mạnh, nhưng nếu như kẻ tấn công tìm hiểu về cơ chế Maintenance Hook này, anh ta có thể thực hiện những hành động nham hiểm hơn nhiều. Cho nên tất cả các Maintenance Hooks cần được loại bỏ [removed] khỏi Software trước khi nó được đưa vào dây chuyền sản xuất.

Chú ý : Nhiều người sẽ nghĩ rằng vì Security ngày nay đã quá phổ biến, nằm trong đầu mọi người nên Maintenance Hooks chỉ là một điều trong quá khứ. Điều này không đúng ! Các nhà phát triển vẫn còn sử dụng Maintenance Hooks, bởi vì sự thiếu hiểu biết của họ hoặc thiếu quan tâm đến vấn đề Security, rất nhiều Maintenance Hooks vẫn còn cư ngụ bên trong các Softwares cũ mà các tổ chức đang sử dụng.

Countermeasures - Biện Pháp Đối Phó

Bởi vì Maintenance Hooks thường được chèn vào bởi các lập trình viên, họ là những người cần phải lấy chúng ra trước khi chương trình đi vào sản xuất. Code Reviews & Unit & Quality Assurance Testing cần phải luôn luôn đặt trên sự giám sát đối với Back-doors, trong trường hợp các lập trình viên đã bỏ sót chúng. Bởi vì Maintenance Hooks là Code nằm bên trong Application hoặc System, không có nhiều người dùng thực sự biết phải làm gì để ngăn chặn chúng, nhưng khi Vendor phát hiện ra Backdoor tồn tại trong sản phẩm của họ, họ thường sẽ phát triển và phát hành ra ngay một bản Patch để giảm thiểu Vulnerability này.

Bởi vì hầu hết các Vendors đều bán Software của họ mà không bao gồm Source Code, đây là một việc rất khó khăn đối với các công ty đã mua Sfotware đó và muốn tự xác định Backdoors. Sau đây là một số biện pháp phòng chống lại Backdoors :

• Sử dụng hệ thống Host-based IDS để giám sát bất kỳ kẻ tấn công nào sử dụng Backdoor bên trong hệ thống. • Sử dụng File System Encryption để bảo vệ thông tin nhạy cảm. • Thực hiện Auditing để phát hiện ra mọi loại hình Backdoor.

Time-of-Check/Time-of-Use Attacks

Các cuộc tấn công đặc biệt có thể tận dụng lợi thế của System Processes requests và thực hiện các nhiệm vụ. Time-of-check/Time-of-use [TOC/TOU] Attack đề cập đến một Sequence of Steps - Chuỗi các bước mà hệ thống sử dụng để hoàn thành một nhiệm vụ. Đây là loại tấn công tận dụng lợi thế của việc phụ thuộc vào Timing của các Events mà diễn ra trong Hệ Điều Hành Multitasking.

Như đã nói qua trước đây, HĐH và Applications trong thực tế chỉ là những lines-of-lines Instructions. HĐH bắt buộc phải thực hiện Instruction 1, sau đó đến Instruction 2, đến Instruction 3, vân vân. Đây là cách nó Written. Nếu kẻ tấn công có thể "chui vào" giữa Instruction 2 và Instruction 3 và thao tác một cái gì đó, anh ta có thể kiểm soát được kết quả của những hoạt động này.

Ví dụ về một cuộc tấn công Time-of-check/Time-of-use :

Process 1 kiểm tra tính hợp lệ Authorization của người dùng để mở một Text File không quan trọng, và Process 2 thực hiện lệnh Mở. Nếu kẻ tấn công có thể thay đổi Text File không quan trọng này với một Critical Password File, trong khi Process 1 đang thực hiện nhiệm vụ của nó, anh ta có thể đạt được khả năng truy cập vào Critical Password File này. [Đây là một lỗ hổng bên trong Code mà cho phép loại thỏa hiệp này diễn ra.]

Chú ý : Kiểu tấn công này còn được gọi là Asynchronous Attack. Asynchronous mô tả một tiến trình mà trong đó Timing của mỗi bước rất có thể thay đổi. Cuộc tấn công sẽ ở giữa những bước này và sửa đổi một cái gì đó. Race Conditions cũng được coi là TOC/TOU Attack bởi một số ngành công nghiệp.

Race Condition là khi 2 Processes khác nhau cần phải thực hiện các nhiệm vụ của chúng trên cùng một Resource. Các Processes cần phải tuân theo đúng trình tự [correct sequence]. Process 1 cần thực hiện nhiệm vụ của nó trước khi Process 2 truy cập đến cùng một Resource và thực hiện nhiệm vụ của Process 2. Nếu Process 2 đi trước Process 1, kết quả có thể rất khác biệt ! Nếu kẻ tấn công có thể thao tác các Processes để cho Process 2 thực hiện trước nhiệm vụ của nó, anh ta có thể kiểm soát được kết quả của Processing Procedure.

Nhìn vào vấn đề này từ góc độ an ninh, có một số loại Race Condition Attacks khá liên quan. Nếu hệ thống Splits up - Chia tách các bước Authentication và Authorization, kẻ tấn công có thể được Authorized trước cả khi anh được Authentication. Ví dụ, theo một trình tự bình thường, Process 1 sẽ kiểm tra xác minh Authentication trước khi cho phép người dùng truy cập đến tài nguyên, sau đó Process 2 sẽ Authorizes cho người dùng truy cập đến tài nguyên. Nếu kẻ tấn công làm cho Process 2 thực hiện nhiệm vụ của mình trước Process 1, anh ta có thể truy cập đến Resource mà không cần hệ thống đảm bảo rằng anh ta đã được Authenticated đúng cách.

Dẫu hai thuật ngữ "Race Condition" và "TOC/TOU Attack" đôi khi được sử dụng để thay thế cho nhau, nhưng trong thực tế chúng là hai việc khác nhau. Race Condition là một cuộc tấn công mà kẻ tấn công làm cho các Processes tiến hành thực thi nằm ngoài trình tự của chúng, mục đích để kiểm soát kết quả. TOC/TOU Attack là khi kẻ tấn công nhảy vào [jumps] giữa 2 Tasks và sửa đổi một cái gì đó để kiểm soát kết quả.

Countermeasures

Sẽ cần phải có một kẻ tấn công chuyên dụng với độ chính xác cao mới có thể thực hiện được những loại tấn công này, nhưng nó có thể và đã được thực hiện. Để bảo vệ chống lại Race Condition Attacks, tốt nhất là không nên Split Up - Phân chia các Critical Tasks mà có thể làm thay đổi trình tự của chúng.

Điều này có nghĩa là hệ thống nên sử dụng Atomic Operations nơi mà chỉ có 1 System Call được sử dụng để Check Authentication và sau đó Grant Access trong 1 Task. Điều này sẽ không cung cấp cho Processor cơ hội để chuyển sang Process khác giữa 2 Tasks. Thật không may, sử dụng các loại Atomic Operations không phải lúc nào cũng có thể.

Để tránh cuộc tấn công TOC/TOU, tốt nhất là HĐH có thể áp dụng Software Locks đến các Items, nó sẽ được sử dụng để "Checking" Tasks. Vì vậy nếu người dùng yêu cầu truy cập đến một File, trong khi hệ thống đang kiểm tra xác minh Authorization của người dùng này, nó cần đặt Software Lock lên File đã được Requested.

Điều này nhằm đảm bảo cho File không thể bị xóa hoặc bị thay đổi với một File khác. Việc áp dụng Locks có thể được thực hiện dễ dàng lên các Files, nhưng nó sẽ khó khăn hơn khi áp dụng Locks lên các thành phần Database và Table Entries để cung cấp loại bảo vệ này.

Buffer Overflows

Ngày nay, nhiều người đã biết đến thuật ngữ Buffer Overflow và định nghĩa cơ bản của nó, nhưng điều quan trọng là các chuyên gia bảo mật phải hiểu rõ được những gì thực sự diễn ra khi xuất hiện lỗ hổng Buffer Overflow.

Buffer Overflow - Lỗi tràn bộ đệm sẽ diễn ra khi có quá nhiều dữ liệu được chấp nhận là Input của một Application hoặc HĐH. Buffer - Vùng Đệm là một Allocated Segment of Memory - Đoạn bộ nhớ được phân bổ. Buffer có thể bị Overflowed - Tràn khi có quá nhiều dữ liệu đầu vào do những kẻ tấn công gây ra, Code được chèn vào vùng Buffer cần phải có một Specific Length - Độ dài cụ thể, theo sau bởi các Commands mà kẻ tấn công muốn thực thi.

Vì vậy, mục đích của Buffer Overflow có thể là một mớ hỗn độn, bằng cách đẩy dữ liệu tùy ý vào bên trong các Memory Segments khác nhau, hoặc để thực hiện một nhiệm vụ cụ thể, bằng cách Pushing - Đẩy vào trong Memory Segment một cách cẩn thận Crafted Set of Data mà sẽ hoàn thành một nhiệm vụ cụ thể. Nhiệm vụ này có thể là mở một Command Shell với đặc quyền Administrative hoặc thực thi Malicious Code.

Chúng ta hãy tìm hiểu sâu hơn chút về cách thực hiện vấn đề này. Softwae có thể được viết ra để chấp nhận dữ liệu từ User, Website, Database hoặc Application khác. Dữ liệu đã được chấp nhận cần một điều gì đó xảy ra với nó, bởi vì nó đã được chèn vào cho một số loại thao tác hoặc tính toán, hoặc được sử dụng như một Parameter được truyền đến một Procedure.

Procedure là Code mà có thể thực hiện một loại hình Function cụ thể trên Data và trả kết quả về cho Requesting Software, như trong Figure 5-21.

Khi Programmer viết ra một mẩu [piece] Software mà sẽ chấp nhận dữ liệu [accept data], dữ liệu này sẽ được lưu trữ trong một Variable - Biến. Khi Software này Call đến Procedure để thực hiện một số loại chức năng, nó sẽ Stacks - Xếp chồng các Instructions và Data trong một Memory Segment dành cho Procedure để Read. [Memory Stacks đã được giải thích trong phần trước, nhưng chúng ta sẽ đi qua thêm lần nữa].

Data được chấp nhận từ một Outside Entity - Thực thể bên ngoài được đặt vào trong một Variable. Variable này cần phải có một nơi [place] để Live trong Memory, gọi là Buffer.

Buffer giống như là một Memory Container dành cho Data. Buffer cần có kích thước đúng để chấp nhận dữ liệu được nhập vào. Vì vậy, nếu Input được coi là 1 Ký Tự, Buffer nên có kích thước là 1 Byte. Nếu lập trình viên không đảm bảo rằng chỉ có duy nhất 1 Byte dữ liệu được chèn vào Software, khi đó một người nào đó có thể nhập vào một vài ký tự cùng một lúc, do đó xảy ra Buffer Overflow.

Buffer lưu trữ Data, được đặt vào một Memory Stack. Bạn có thể tưởng tượng Buffer giống như là một chiếc thùng nhỏ để đựng nước [data]. Chúng ta có những chiếc thùng nhỏ Stacked - Được Xếp Chồng lên nhau, chiếc này lại xếp chồng lên đầu của chiếc kia, và nếu như có quá nhiều nước được đổ vào chiếc thùng ở trên cùng [top bucket], nó sẽ tràn nước vào những chiếc thùng bên dưới nó [Buffer Overflow] và Overwrites - Ghi đè các Instructions và Data lên Memory Stack.Chú ý : Bạn không cần phải biết ngôn ngữ lập trình C trong kỳ thi CISSP. Đối với kỳ thi CISSP, bạn chỉ cần nắm được khái niệm tổng thể của Buffer Overflow là được rồi.

Vì Stack chỉ là một Segment trong Memory, mà cho phép việc giao tiếp [communication] diễn ra giữa Requesting Application và Procedure hoặc Subroutine. Khả năng các Problems tràn bộ đệm có thể xảy ra khi Requesting Application không thực hiện Bounds Checking đúng cách, để đảm bảo dữ liệu được nhập vào có một chiều dài chấp nhận được. Nhìn vào đoạn mã C sau đây để cách việc này có thể xảy ra như thế nào :

include

int main[int argc, char **argv] { char buf1 [5] = "1111"; char buf2 [7] = "222222"; strcpy [buf2, "3333333333"]; printf ["%s\n", buf2]; printf ["%s\n", buf1]; return 0; }

Ở đây, chúng ta đang thiết lập một Buffer [Buf1] để lưu trữ 4 Ký Tự và Null Value, cùng với một Buffer thứ 2 [buf2] để lưu trữ 6 ký tự và Null Value. [Null vales chỉ ra nơi kết thúc của Buffer trong Memory]. Nếu ta xem xét những Buffers này, chúng ta sẽ thấy như sau :

Buf2 \0 2 2 2 2 2 2 Buf1 \0 1 1 1 1

Application sau đó chấp nhận 10 con số 3 vào trong Buf2, nhưng mà Buf2 lại chỉ có thể lưu trữ 6 ký tự mà thôi. Cho nên 6 Variables trong Buf2 sẽ được làm đầy và 4 Variables còn lại trong Buf1 cũng sẽ được làm đầy, Overwriting - Ghi đè lên nội dung của Buf1. Điều này diễn ra bởi vì command Strcpy đã không chắc chắn rằng Buffer có đủ độ lớn để chứa nhiều Values. Vì vậy bây giờ nếu chúng ta nhìn vao 2 Buffers này, chúng ta sẽ thấy nó thay đổi như sau :

Buf2 \0 3 3 3 3 3 3 Buf1 \0 3 3 3 3

Nhưng thực tế sẽ có những thứ thú vị hơn xuất hiện khi Return Pointer thực sự bị ghi đè, như trong Figure 5-22. Trong một cuộc tấn công Buffer Overflow, Stack sẽ được làm đầy [filled] đúng cách để Return Pointer có thể bị ghi đè và Control đưa ra các Malicious Instructions mà đã được nạp vào Stack thay vì quay lại Requesting Application. Điều này cho phép Malicious Instructions được thực thi trong bối cảnh an ninh của Requesting Application. Nếu Application đang vận hành trong chế độ Privileged Mode, kẻ tấn công sẽ có thêm nhiều Permissions để thực hiện và gây ra nhiều thiệt hại hơn.

Kẻ tấn công cần phải biết được kích thước của Buffer để ghi đè và cần phải biết các Addresses mà đã được assigned cho Stack. Nếu không biết các Addresses này, anh ta sẽ không thể nào hạ Return Pointer đến Malicious Code của anh ta. Kẻ tấn công cũng cần phải viết ra những Payload nguy hiểm đủ nhỏ để nó có thể được truyền vào như một Input từ 1 Procedure tiếp theo.

Core của Windows được viết bằng ngôn ngữ C và có nhiều Layers & Layers của các đoạn code Object-oriented. Khi có một Procedure cần Call đến HĐH để thực hiện một loại công việc nào đó, nó sẽ call đến System Service thông qua API call. API giống như là một con đường dẫn đến Functionality của HĐH.

Ngôn ngữ C là dễ bị tấn công Buffer Overlow nhất, bởi vì nó cho phép các thao tác Pointer trực tiếp diễn ra. Các Commands đặc thù có thể cung cấp khả năng truy cập đến Low-level Memory Addrsses mà không thực hiện Bounds Checking - Kiểm Tra Giới Hạn. C Functions để thực hiện Boundary Checking cần thiết bao gồm : strncpy[], strncat[], snprintf[] và vsnprintf[].

HĐH bắt buộc phải được viết ra để làm việc với một CPU Architectures đặc thù nào đó. Các Architectures này đưa ra các System Memory Addressing, Protection Mechanisms, và Mode of Execution và làm việc với các Instruction Sets cụ thể. Điều này có nghĩa là một tấn công Buffer Overflow mà hoạt động trên chip Intel sẽ không nhất thiết hoạt động được trên Motorola Processor hoặc SPARC Processor.

Những bộ vi xử lý khác nhau sẽ thiết lập Memory Address của các Stacks khác nhau, do đó kẻ tấn công có thể đưa ra một Buffer Overflow Code cho những nền tảng khác nhau. Điều này thường không phải là một trở ngại, kể từ khi hầu hết các đoạn Code đều đã được viết và luôn có sẵn trên những Websites chuyên vấn đề Hacking.

Countermeasures - Biện pháp đối phó Buffer Overflow.

Buffer Overflow trong mã nguồn của các Applications và các HĐH khác nhau. Chúng đã ở khắp nơi từ khi các nhà lập trình viên bắt đầu phát triển Software. Điều này có nghĩa là nó rất khó khăn để một người dùng bình thường có thể xác định và sửa chữa nó. Khi Buffer Overflow được xác định thông thường Vendor sẽ tung ra một bản Patch. Vì vậy, hãy giữ cho các hệ thống luôn luôn được Updates, Hotfix và Patches up-to-date, thông thường đó là biện pháp đối phó tốt nhất.

Một số sản phẩm Host-based IPS cũng có thể được cài đặt lên hệ thống để giám sát các giá trị Input mà có thể dẫn đến kết quả Buffer Overflows. Nhưng Countermeasure tốt nhất chính là Proper Programming - Lập Trình Đúng Đắn. Điều này có nghĩa là sử dụng Bounds Checking. Nếu Input value chỉ được cho là có 9 ký tự, thì Application chỉ nên chấp nhận 9 ký tự mà thôi !

Một số ngôn ngữ lập trình còn nhạy cảm với vấn đề Buffer Overflows hơn cả những ngôn ngữ khác. Cho nên lập trình viên cần phải hiểu những vấn đề này, sử dụng đúng ngôn ngữ cho đúng mục đích, và thực hiện Code Review để xác định Buffer Overflow Vulnerabilities.