Хочу поділитися досвідом проектування дозволів на файлових серверах. У теорії та практиці і Unix і Windows (як дві найбільш популярні платформи) надають достатньо коштів і можливостей для призначення дозволів на об'єкти на файл серверах. Це досить пересічне завдання, коли у вас до сотні користувачів, пара серверів, і всього кілька рівнів вкладеності дерева каталогів. При зростанні колічества серверів, колічестве каталогів, та й користувачів у таких компаніях набагато більше, з'являється неприємна обставина - різко зростають витрати на підтримку інфраструктури загального доступу до файлів (час і персонал). У даній топіці хочеться розповісти про основні вимоги до дизайну сервісу загального доступу до файлів, що дозволить при їх виконанні спростити підтримку і скоротити витрати на неї. Заздалегідь звертаю увагу, що не торкаємося самого процесу вмісту серверів (заліза, фалових та оперційних систем) і утримання об'єктів (типи контенту), а розглядаємо тільки дизайн структури загального доступу.
Опишемо стразу умови які будемо розглядати як приклад і реальне застосування.
У наявності на даний момент:
- П "ять основних серверів спільного доступу до файлів
- Більше п "яти рівнів вкладення на кожному сервері
- Понад 500 каталогів на кожному сервері
- Понад 10 тис. файлів на кожному сервері
- Понад 300 користувачів
Географічне розташування серверів, користувачів, мережева інфраструктура не має особливого значення для даної ситуації.
У результаті використання такої іфраструктури протягом кількох років, зміни декількох системних адміністраторів, регулярного призначення спеціальних дозволів на каталогах (цілі не важливі) за запитами користувачів, навіть при ретельному веденні документації, дотримання процесів внесення зміни і ведення подій про зміни в інфраструктурі на подібних серверах виникає бардак у дозволах каталогів. Типовий прояв безладу: необхідно зрозуміти чому користувач Іванова Ольга (перекладач наприклад) має доступ до каталогу з інформацією про фінанси, та й ще може її редагувати до того ж. Відкриваємо дозволи каталогу, моделюємо ефективні дозволи на доступ для цього користувача і бачимо що таки вона може там хоч метеликів розводити, хоча судячи з членства в групах на два рівні вище її там і не повинно бути ніяк. Виникає питання: як склалася дана ситуація? Напевно причиною є успадкування дозволів, хоча може бути так само і які-небудь особливі дозволи які на перший погляд не видно. Може бути і зворотна ситуація коли якийсь користувач не може отримати доступ до документів які йому належно редагувати, і тут вже необхідно витратити, як правило, набагато більше часу на пошук причин і виправлення помилок. Все це призводить до великих витрат часу які насправді можна було уникнути при правильному плануванні і дотриманні дизайну.
Що ж можна запропонувати як вирішення даної ситуації (а як далі побачимо і більшості інших виникаючих на файлових серверах). Для початку це розробка дизайну для файлової інфраструктури загального доступу. Дизайн повинен складатися з документа, що описує як мінімум наступні області:
- мета
- користь яку принесе дотримання даної політки
- область застосування
- вимоги до логічної структури файлового доступу
- потреба дозволити доступ до об "єктів загального доступу
- ролі які необхідні/будуть брати участь у проектуванні, впровадженні, підтримці даної інфраструктури
- ризики при впровадженні та підтримці інфраструктури
- основні проблеми, які можуть бути при проектуванні, впровадженні, підтримці
- зв'язки з будь-якими іншими політиками, угодами, контрактами які можуть вплинути на дизайн, впровадження і підтримку сервісу загального доступу до файлів
Хочу зупинитися на вимогах до логічної структури і дозволів доступу, опис інших же розділів дизайну відноситься вже до області сервіс-менеджменту і виходить за рамки даного топіка.
Основні рекомендації дозволяють уникнути багатьох помилок за підтримки сервісу:
- Для логічної структури дерева каталогів найкраще використовувати єдиний дизайн на всіх серверах
- На всіх серверах рекомендується використовувати однакову точку входу до каталогів (root level)
- Всі каталоги які повинні мати особливі права доступу повинні мати власні групи для користувачів яким необхідний доступ саме в цей каталог
- Для надання доступу до каталогів рекомендується використовувати окремі групи користувачів які слід розміщувати в окремому від інших груп контейнері
- Всі групи для надання доступу повинні мати єдиний заздалегідь визначений дизайн іменування
- Дозволи на каталоги можна видавати тільки через включення в члени групи яка відповідає даному каталогу (ніколи окремому користувачеві безпосередньо)
- При виставленні дозволів для новоствореного каталогу всі системні ненадані групи доступу повинні видалятися
- Успадкування дозволів повинно бути увімкнено починаючи з кореневого каталогу (root level) і не повинно відключатися ні при яких ситуаціях
- Доступ до об'єктів можна надавати тільки шляхом надання двох основних наборів прав - на читання (читання списку об'єктів, читання дозволів, читання вмісту) і на зміну (права на читання + зміна вмісту, видалення файлів і коталогів, створення файлів і каталогів). В окремих випадках можна використовувати спеціальні групи (окремий тип груп), які можуть надавати лише необхідну частину з двох основних повних наборів прав доступу
- Забороняється використовувати «заборону доступу» (deny of access) ні за яких умов
- Рекомендується використовувати ABE при необхідності приховати від очей зайві каталоги або ж при необхідності не тільки заборонити доступ, а й у міру можливості забезпечити видимість їх відсутності
Особливу увагу за підтримки загального доступу до файлів варто приділяти останнім трьом пунктам, бо порушення будь-якого з них сильно ускладнює розслідування інцидентів і подальше пректування і розвиток сервісу. Будь-які необхідні дії з різачами на доступ можна виконати в рамках останніх трьох пунктів.
Дотримання цих правил робить ваш сервіс надання загального доступу масштабованим, зрозумілим будь-якому інженеру, більш безпечним. Основним результатом буде явне зниження витрат на підтримку сервісу і зниження деяких ризиків.
P.S.
Інші розділи дизайну (цілі, ризики, ролі, зв'язки з іншими політиками) в даному випадку не менш важливі для оптимального і успішного проектування, впровадження і підтримки сервісу. З чого слід необхідність приділяти їм не менше уваги ніж дизайну дозволу або підтримці порядку в структурі каталогів.
Щоб уникнути холівара з приводу пункту 10. відразу хочу додати, що будь-яку заборону доступу можна замінити правильно спроектованими дозволами. Використання «Deny Access» сильно ускладнює розслідування інцидентів при великих рівнях вкладеності, але і при малих теж може доставити багато клопоту. Відповідно використання спадкування і тільки дозволяючих наборів прав доступу дає впевненість у прозорому механізмі спадкування і що ніде між кількома рівнями нічого не приховано від вас.
З ABE необхідно бути дуже акуратним і пам'ятати про його наявність, в іншому випадку буде багато здивування при розслідуванні інцидентів.
