Як влаштована та працює система контролю доступу в Squid - Записки IT фахівця
Технічний блог фахівців ТОВ "Інтерфейс"
- Головна
- Як влаштована та працює система контролю доступу в Squ >
Система контролю доступу Squid і двох різних частин:елементів ACL (ACL elements) ісписків доступу (access lists). Тут прихована перша складність, яка пов'язана з перекладом українською мовою термінів, що використовуються. ТакACL elements найчастіше перекладається якACL записи чиACL списки, що, загалом, досить чітко відбиває їх зміст, але викликає плутанину з терміномaccess lists, замість якого найчастіше використовується термінправила ACL. Найчастіше плутанина виникає при самостійному перекладі англомовної документації, що різко ускладнює розуміння і призводить до різноманітних казусів.
Елементи ACL
Також можна записати це так:
При виборі варіанта написання слід виходити з його зручності читання, на наш погляд другий варіант більш зручний у сприйнятті, ніж перший.
Ви можете створити будь-яку кількість елементів ACL, як-то кажуть, на всі випадки життя, але при цьому слід пам'ятати, що всі значення елементів завантажуються в пам'ять при старті сервісу і кожне значення перевіряється по кожному елементу відповідного типу.
За часом роботи розрізняють два типи ACL: швидкі таповільні. До повільних відносять елементи, пов'язані з необхідністю виконувати DNS-запити, автентифікацію користувачів тощо з повним списком повільних і швидких ACL можна ознайомитися тут: Fast and Slow ACLs. По зрозумілих причин повільними елементами ACL не слід зловживати.
Списки доступу
Елементи ACL самі по собі не здійснюють жодних дій, це просто списки, які використовуються іншою частиною системи контролю доступу – списками доступу (або правилами). Список списків доступу також досить великий і повністю з ним можна ознайомитися тут: Access Lists.
Загальний синтаксис такий:
Ось тут починається найцікавіше. Кожен список доступу може містити кілька елементів ACL, які обробляються за принципом І, тобто. щоб список спрацював, значення має входити до всіх елементів ACL.
Самі списки обробляються послідовно, за принципом АБО, тобто. до першого збігу.
Якщо значення не потрапило до жодного списку певного типу, до нього застосовується дія протилежна дії в останньому списку. Ця особливість здатна призвести до вельми несподіваного результату, тому хорошим тоном завжди задаватиме дія за умовчанням, вказуючи замість елемента ACL значенняall.
Простий приклад. Спочатку ми дозволили всім підрозділам доступ до Інтернету через протокол HTTP, але не задали при цьому стандартні дії:
У наведеному прикладі все буде працювати як треба, всі комп'ютери, які не відносяться до зазначених елементів ACL доступу до мережі, не будуть мати. А тепер ми вирішили заблокувати доступ до мережі для складу:
Після чого будь-який комп'ютер мережі, окрім вхідних в елемент sklad отримає доступ, так як для всіх значень, що не потрапили в списки, дія будеallow. Тому завжди ставте дію за замовчуванням:
Часто виникає таке питання: а чи можна замість конструкції
Начебто скрізь allow , навіщо плодити рядки? Відповідь – не можна! Тому що списки (правила) обробляються як АБО, а елементи як І. А оскільки один і той же комп'ютер, незважаючи на те, що мережа бухгалтерії входить до мережі офісу, не може одночасно належати офісу та складу, то таке правило працювати не буде .
Дуже простий приклад:
Якщо ми напишемо так, то буде працювати:
А от так не буде:
тому що цей запис означає:
чого просто не може бути, тому що джерело може бутиІвановим АБО Петровим, але ніяк неІвановим І Петровим одночасно.
Взагалі, уникайте поєднувати в одному списку доступу елементи ACL одного типу, це найвірніший спосіб отримати неробоче правило.
При вказівці списків доступу пам'ятайте про черговість, тому все більш приватні правила повинні розташовуватися перед більш загальними, навіть якщо всі ці списки доступу мають одну і ту ж дію. Згодом ви можете змінити дію в одному з правил і отримати несподіваний результат.
Тому правильно буде:
Припустимо, надійшло завдання - обмежити доступ до інтернету робочим часом для всієї бухгалтерії, крім Іванова. Добре, додаємо:
Потім додамо до вирішального списку другий елемент ACL і заборонимо роботу у неробочий час:
На перший погляд це може здатися елементарним і очевидним, але насправді, коли правил багато і розташовані вони впереміш, пошук списків, що перекриваються, може зайняти багато часу і потріпати чимало нервів як вам, так і користувачам.
На прикладі вище ми неявно торкнулися ще однієї теми при використанніелементів ACL, що перекриваються, завжди створюйте списки для всіх можливих поєднань умов. Наприклад, конструкція:
працювати не буде, тому що в робочий час спрацьовуватиме правилоhttp_access allow buh worktime, а в неробочеhttp_access allow office, тому що список значень елементаbuh перекривається списком значень елементаoffice. Щоб усе працювало як задумано, знадобиться ще один списокhttp_access deny buh :
Причому він повинен розташовуватися строго на своєму місці, пересунувши його вище, ми повністю заблокуємо доступ для бухгалтерії, а пересунувши нижче, перекриємо його дію вирішальним правилом для всього офісу.
Так само, як і елементи ACL списки доступу можуть бути швидкими та повільними: Fast and Slow ACLs. Наприклад, списки доступуdelay_access, які відповідають за обмеження швидкості, є швидкими, аhttp_access - повільними. Загальне правило: використовувати швидкі списки раніше повільних та не використовувати швидкі списки з повільними елементами. Також має сенс вводити деякі "непотрібні" перевірки, щоб зменшити кількість звернень до повільних списків з повільними елементами.