Сервер аутентифікації Kerberos. 4 страница

Із цілей виводяться правила безпеки, що описують, хто, що й при яких умовах може робити. Що докладніше правила, що більш формально вони викладені, тим простіше підтримати їхнє виконання програмно-технічними засобами. З іншого боку, занадто жорсткі правила можуть заважати роботі користувачів, імовірно, їх доведеться часто переглядати. Керівництво повинно знайти розумний компроміс, коли за прийнятну ціну буде забезпечений прийнятний рівень безпеки, а співробітники не виявляться надмірно зв'язані. Зазвичай найбільш формально висуваються права доступу до об'єктів через особливу важливість даного питання.

4.3. Програма безпеки

Після того, як сформульована політика безпеки, можна приступати до складання програми її реалізації і безпосередньо до реалізації.

Щоб зрозуміти й реалізувати яку-небудь програму, її потрібно структурувати по рівнях, звичайно у відповідності зі структурою організації. У найпростішому й найпоширенішому випадку досить двох рівнів - верхнього, або центрального, котрий охоплює всю організацію, і нижнього, або службового, котрий стосується окремих послуг або груп однорідних сервісів.

Програму верхнього рівня очолює особа, відповідальна за інформаційну безпеку організації. У цієї програми наступні головні цілі:

* керування ризиками (оцінка ризиків, вибір ефективних засобів захисту);

« координація діяльності в області інформаційної безпеки, поповнення й розподіл ресурсів;

* стратегічне планування;

* контроль діяльності в області інформаційної безпеки.

У рамках програми верхнього рівня приймаються стратегічні рішення із забезпечення безпеки, оцінюються технологічні новинки. Інформаційні технології розвиваються дуже швидко, і необхідно мати чітку політику відстеження й впровадження нових засобів.

Контроль діяльності в області безпеки має двосторонню спрямованість. По-перше, необхідно гарантувати, що дії організації не суперечать законам. При цьому варто підтримувати контакти із зовнішніми контролюючими організаціями. По-друге, потрібно постійно відслідковувати стан безпеки усередині організації, реагувати на випадки порушень і доопрацьовувати захисні заходи з урахуванням зміни обстановки.

Варто підкреслити, що програма верхнього рівня повинна займати певне місце в діяльності організації, вона повинна офіційно прийматися й підтримуватися керівництвом, а також мати певний штат і бюджет.

Ціль програми нижнього рівня - забезпечити надійний й економічний захист конкретного сервісу або групи однорідних сервісів. На цьому рівні вирішується, які варто використовувати механізми захисту; закуповуються й установлюються технічні засоби; виконується повсякденне адміністрування; відслідковується стан слабких місць і т.п. Звичайно за програму нижнього рівня відповідають адміністратори сервісів.

4.4. Синхронізація програми безпеки з життєвим циклом систем

Якщо синхронізувати програму безпеки нижнього рівня з життєвим циклом захищуваного сервісу, можна домогтися більшого ефекту з меншими витратами. Програмісти знають, що додати нову можливість до вже готової системи на порядок складніше, ніж з нуля спроектувати й реалізувати її. Та ж умова виконується для інформаційної безпеки.

У життєвому циклі інформаційного сервісу можна виділити наступні етапи:

Ініціація. На даному етапі виявляється необхідність у придбанні нового сервісу, документується його передбачуване призначення.

Закупівля. На даному етапі складаються специфікації, проробляються варіанти придбання, виконується власне закупівля.

Установка. Сервіс установлюється, конфігурується, тестується й уводиться в експлуатацію.

Експлуатація. На даному етапі сервіс не тільки працює й адмініструється, але й піддається модифікаціям.

Виведення з експлуатації. Відбувається перехід на новий сервіс.

Розглянемо дії, виконувані на кожному з етапів, більш докладно.

На етапі ініціації оформляється розуміння того, що необхідно придбати новий або значно модернізувати існуючий сервіс; визначається, якими характеристиками і якою функціональністю він повинен володіти; оцінюються фінансові й інші обмеження.

З погляду безпеки найважливішою дією тут є оцінка критичності як самого сервісу, так і інформації, що з його допомогою буде оброблятися. Потрібно сформулювати відповіді на наступні питання:

* якого роду інформація призначається для обслуговування новим сервісом?

* які можливі наслідки порушення конфіденційності, цілісності та доступності цієї інформації?

* які загрози, стосовно яких сервіс та інформація будуть найбільш уразливі?

* чи є які-небудь особливості нового сервісу (наприклад, територіальна роззосередженість компонентів), що вимагають прийняття спеціальних процедурних заходів?

* які характеристики персоналу, що має відношення до безпеки (кваліфікація, благонадійність)?

* які законодавчі положення й внутрішні правила, яким повинен відповідати новий сервіс?

Результати оцінки критичності є відправною крапкою в складанні специфікацій. Крім того, вони визначають ту міру уваги, яку служба безпеки організації повинна приділяти новому сервісу на наступних етапах його життєвого циклу.

Етап закупівлі - один із найскладніших. Потрібно остаточно сформулювати вимоги до захисних засобів нового сервісу, до компанії, що може претендувати на роль постачальника, і до кваліфікації, якою повинен володіти персонал, що використовує або обслуговує закуплений продукт. Усі ці відомості оформляються у вигляді специфікації, куди входять не тільки апаратура й програми, але й документація, обслуговування, навчання персоналу. Зрозуміло, особлива увага повинна приділятися питанням сумісності нового сервісу з існуючою конфігурацією. Підкреслимо також, що нерідко засоби безпеки є необов'язковими компонентами комерційних продуктів, і потрібно простежити, щоб відповідні пункти не випали зі специфікації.

Коли продукт закуплений, його необхідно встановити. Незважаючи на можливу простоту, установка є дуже відповідальною справою. По-перше, новий продукт треба сконфігурівати. Як правило, комерційні продукти постачаються з вимкненими засобами безпеки; їх необхідно увімкнути й належним чином налаштувати. Для великої організації, де багато користувачів і даних, початкове налаштування може стати досить працеємною й відповідальною справою.

По-друге, новий сервіс має потребу в процедурних регуляторах. Варто подбати про чистоту й охорону приміщення, про документи, шо регламентують використання сервісу, про підготовку планів на випадок екстрених ситуацій, про організацію навчання користувачів і т.п.

Після прийняття перерахованих заходів необхідно провести тестування. Його повнота й комплексність можуть бути гарантією безпеки експлуатації в штатному режимі.

Період експлуатації - найтриваліший і складний. Із психологічної точки зору найбільшу небезпеку в цей час становлять незначні зміни в конфігурації сервісу, у поводженні користувачів й адміністраторів. Якщо безпеку не підтримувати, вона слабшає. Користувачі не настільки чітко виконують посадові інструкції, адміністратори менш ретельно аналізують реєстраційну інформацію. То один, то інший користувач одержує додаткові привілеї. Здається, що в сутності нічого не змінилося; насправді ж від колишньої безпеки не залишилося й сліду.

Для боротьби з ефектом повільних змін доводиться долучатися до періодичних перевірок сервісу безпеки. Зрозуміло, після значних модифікацій подібні перевірки є обов'язковими.

При виведенні з експлуатації зачіпаються апаратно-програмні компоненти сервісу й оброблювані ними дані. Апаратура продається, утилізується або викидається. Тільки в специфічних випадках необхідно піклуватися про фізичне руйнування апаратних компонентів, що зберігають конфіденційну інформацію. Програми, імовірно, просто стираються, якщо інше не передбачено ліцензійною угодою.

При виведенні даних з експлуатації їх звичайно переносять на іншу систему, архівують, викидають або знищують. Якщо архівування робиться з наміром згодом прочитати дані в іншому місці, варто подбати про апаратно-програмну сумісність засобів читання й запису. Інформаційні технології розвиваються дуже швидко, і через кілька років пристроїв, здатних прочитати старий носій, може просто не виявитися. Якщо дані архівуються в зашифрованому вигляді, необхідно зберегти ключ і засоби розшифровки. Під час архівування й зберігання архівної інформації не можна забувати про підтримку конфіденційності даних.

Розділ 5. Керування ризиками

5.1. Основні поняття

Керування ризиками розглядається нами на адміністративному рівні ІБ, оскільки лише керівництво організації здатне виділити необхідні ресурси, ініціювати й контролювати виконання відповідних програм.

Загалом кажучи, керування ризиками, так само як і вироблення власної політики безпеки, актуально тільки для тих організацій, інформаційні системи яких й/або оброблювані дані можна вважати нестандартними. Звичайну організацію цілком улаштує типовий набір захисних заходів обраних на основі подання про типові ризики або взагалі без усякого аналізу ризиків. Можна провести аналогію між індивідуальним будівництвом й одержанням квартири в районі масової забудови. У першому випадку необхідно прийняти безліч рішень, оформити велику кількість паперів, у другому досить визначитися лише з декількома параметрами.

Використання інформаційних систем пов'язане з певною сукупністю ризиків. Коли можливий збиток неприйнятно великий, необхідно прийняти економічно виправдані заходи захисту. Періодична (пере)оцінка ризиків необхідна для контролю ефективності діяльності в області безпеки й для обліку змін обстановки.

З кількісної точки зору рівень ризику є функцією ймовірності реалізації певної загрози (використовуючи деякі уразливі місця), а також величини можливого збитку.

Таким чином, суть заходів щодо керування ризиками полягає в тому, щоб оцінити їхній розмір, виробити ефективні й економічні заходи зниження ризиків, а потім переконатися, що ризики укладені в прийнятні рамки (і залишаються такими). Отже, керування ризиками містить у собі два види діяльності, які чергуються циклічно:

* (пере)оцінка (вимір) ризиків;

* вибір ефективних та економічних захисних засобів (нейтралізація ризиків).

Стосовно виявлених ризиків можливі наступні дії:

* ліквідація ризику (наприклад, за рахунок усунення причини);

« зменшення ризику (наприклад, за рахунок використання додаткових захисних засобів);

* прийняття ризику (і вироблення плану дії у відповідних умовах);

* переадресація ризику (наприклад, шляхом висновку страхової угоди). Процес керування ризиками можна розділити на наступні етапи:

1. Вибір аналізованих об'єктів і рівня деталізації їхнього розгляду.

2. Вибір методології оцінки ризиків.

3. Ідентифікація активів.

4. Аналіз загроз та їхніх наслідків, виявлення уразливих місць у захисті.

5. Оцінка ризиків.

6. Вибір захисних заходів.

7. Реалізація й перевірка обраних заходів.

8. Оцінка залишкового ризику.

Етапи 6 та 7 відносяться до вибору захисних засобів (нейтралізації ризиків), інші - до оцінки ризиків.

Уже перелік етапів показує, що керування ризиками - процес циклічний. Власне кажучи, останній етап - це оператор кінця циклу, що пропонує повернутися до початку. Ризики потрібно контролювати постійно, періодично проводячи їхню переоцінку. Відзначимо, що сумлінно виконана й ретельно документована перша оцінка може істотно спростити наступну діяльність.

Керування ризиками, як і будь-яку іншу діяльність в області інформаційної безпеки, необхідно інтегрувати в життєвий цикл ІС. Тоді ефект виявляється найбільшим, а витрати - мінімальними. Раніше ми визначили п'ять етапів життєвого циклу. Коротко опишемо, що може дати керування ризиками на кожному з них.

На етапі ініціації відомі ризики варто врахувати при виробленні вимог до системи взагалі й засобів безпеки зокрема.

На етапі закупівлі (розробки) знання ризиків допоможе вибрати відповідні архітектурні рішення, які відіграють ключову роль у забезпеченні безпеки.

На етапі установки виявлені ризики варто враховувати при конфігуруванні, тестуванні й перевірці раніше сформульованих вимог, а повний цикл керування ризиками повинен передувати впровадженню системи в експлуатацію.

На етапі експлуатації керування ризиками повинно супроводжувати всі істотні зміни в системі.

При виведенні системи з експлуатації керування ризиками допомагає переконатися в тім, що міграція даних відбувається безпечним чином.

5.2. Підготовчі етапи керування ризиками

У цьому розділі будуть описані перші три етапи процесу керування ризиками.

Вибір аналізованих об'єктів і рівня деталізації їхнього розгляду - перший крок в оцінці ризиків. Для невеликої організації припустимо розглядати всю інформаційну інфраструктуру; однак якщо організація велика, всеохоплююча оцінка може вимагати неприйнятних витрат часу й сил. У такому випадку варто зосередитися на найбільш важливих сервісах, заздалегідь погоджуючись із наближеністю підсумкової оцінки. Якщо важливих сервісів усе ще багато, вибираються ті з них, ризики для яких свідомо великі або невідомі.

Ми вже вказували на доцільність створення карти інформаційної системи організації. Для керування ризиками подібна карта особливо важлива, оскільки вона наочно показує, які сервіси обрані для аналізу, а якими довелося знехтувати. Якщо ІС змінюється, а карта підтримується в актуальному стані, то при переоцінці ризиків відразу стане ясно, які нові або істотно змінені сервіси мають потребу в розгляді.

Загалом кажучи, уразливим є кожен компонент інформаційної системи -від мережевого кабелю, який можуть прогризти миші, до бази даних, що може бути зруйнована через невмілі дії адміністратора. Як правило, у сферу аналізу неможливо включити кожен гвинтик і кожен байт. Доводиться зупинятися на деякому рівні деталізації, усвідомлюючи наближеність оцінки. Для нових систем кращий детальний аналіз; стара система, яка піддається незначним модифікаціям, може бути проаналізована більш поверхнево.

Дуже важливо вибрати розумну методологію оцінки ризиків. Метою оцінки є одержання відповіді на два питання: чи прийнятні існуючі ризики, і якщо ні, то які захисні засоби варто використовувати. Виходить, оцінка повинна бути кількісною, що допускає зіставлення із заздалегідь обраними межами допустимості й витратами на реалізацію нових регуляторів безпеки. Керування ризиками - типова оптимізація завдання, й існує досить багато програмних продуктів, здатних допомогти в її вирішенні (іноді подібні продукти просто додаються до книг з інформаційної безпеки). Принципові труднощі, однак, складаються в неточності вихідних даних. Можна, звичайно, спробувати одержати для всіх аналізованих величин грошовий вираз, вирахувати все з точністю до копійки, але особливого сенсу в цьому немає. Практичніше користуватися умовними одиницями. У найпростішому й цілком припустимому випадку можна користуватися трибальною шкалою. Далі ми продемонструємо, як це робиться.

При ідентифікації активів, тобто тих ресурсів і цінностей, які організація намагається захистити, треба, звичайно, ураховувати не тільки компоненти інформаційної системи, але й підтримуючу інфраструктуру, персонал, а також нематеріальні цінності, такі як репутація організації. Відправною крапкою тут є уявлення про місію організації, у будь-якому випадку напрямки діяльності, які бажано (або необхідно) зберегти в кожному разі. Висловлюючись об'єктно-орієнтованою мовою, треба в першу чергу описати зовнішній інтерфейс організації, розглянутої як абстрактний об'єкт.

Одним з головних результатів процесу ідентифікації активів є одержання детальної інформаційної структури організації й способів її (структури) використання. Ці відомості доцільно нанести на карту ІС як межі відповідних об'єктів.

Інформаційною основою якої-небудь великої організації є мережа, тому в число апаратних активів варто включити комп'ютери (сервери, робочі станції, ПК), периферійні пристрої, зовнішні інтерфейси, кабельне господарство, активне мережеве устаткування (мости, маршрутизатори й т.п.). До програмних активів, імовірно, будуть віднесені операційні системи (мережева, сервери! й клієнтські), прикладне програмне забезпечення, інструментальні засоби, де (у яких вузлах мережі) зберігається програмне забезпечення, і з яких вузлів воно використовується. Третім видом інформаційних активів є дані, які зберігаються, обробляються й передаються по мережі. Варто класифікувати дані по типах і ступеню конфіденційності, виявити місця їхнього зберігання й обробки, способи доступу до них. Все це важливо для оцінки наслідків порушень інформаційної безпеки.

Керування ризиками - процес далеко не лінійний. Практично всі його етапи пов'язані між собою, і по завершенню майже кожного з них може виникнути необхідність повернення до попереднього. Так, при ідентифікації активів може виявитися, що обрані межі аналізу варто розширити, а ступінь деталізації - збільшити. Особливо складний первинний аналіз, коли багаторазові повернення до початку неминучі.

5.3. Основні етапи керування ризиками

Етапи, що передують аналізу загроз, можна вважати підготовчими, оскільки прямого зв'язку з ризиками вони не мають. Ризик з'являється там, де є загрози.

Короткий перелік найпоширеніших загроз був розглянутий нами раніше. На жаль, на практиці загроз набагато більше, причому далеко не всі вони носять комп'ютерний характер. Так, цілком реальною загрозою є наявність мишей і тарганів у займаних організацією приміщеннях. Перші можуть зашкодити кабелю, другі викликати коротке замикання. Як правило, наявність тієї або іншої загрози є наслідком недоліків у захисті інформаційної системи, які, у свою чергу, характеризуються відсутністю деяких сервісів безпеки або недоліками в реалізуючих їх захисних механізмах. Небезпека прогризання кабелів виникає не просто там, де с миші, вона пов'язана з відсутністю або недостатньою міцністю захисної оболонки.

Перший крок в аналізі загроз - їхня ідентифікація. Розглянуті види загроз варто вибирати виходячи з міркувань здорового глузду (відкинувши, наприклад, землетрус, однак не забуваючи про можливості захоплення організації терористами), але в межах обраних видів провести максимально докладний аналіз.

Доцільно виявляти не тільки самі загрози, але й джерела їхнього виникнення - це допоможе у виборі додаткових засобів захисту. Наприклад, нелегальний вхід у систему може стати наслідком відтворення початкового діалогу, підбору паролю або підключення до мережі неавторизованого устаткування. Очевидно, для протидії кожному з перерахованих способів нелегального входу потрібні свої механізми безпеки.

Після ідентифікації загрози необхідно оцінити ймовірність її здійснення, Можливе використання при цьому трибальної шкали (низька (1), середня (2) і висока (3) ймовірність).

Крім ймовірності здійснення, важливим є розмір потенційного збитку. Наприклад, пожежі бувають нечасто, але збиток від кожної з них, як правило, великий. Розмір збитку також можна оцінити за трибальною шкалою.

Оцінюючи розмір збитку, необхідно мати на увазі не тільки безпосередні витрати на заміну устаткування або відновлення інформації, але й більш віддалені, такі як підрив репутації, ослаблення позицій на ринку й т.п. Нехай, наприклад, у результаті дефектів у керуванні доступом до бухгалтерської інформації співробітники одержали можливість корегувати дані про власну заробітну платню. Наслідком такого стану справ може стати не тільки перевитрата бюджетних або корпоративних засобів, але й повне розкладання колективу, що може призвести до розвалу організації.

Уразливі місця мають властивість притягати до себе не тільки зловмисників, але й порівняно чесних людей. Не кожен тримається перед спокусою дещо збільшити свою зарплатню, якщо є впевненість, що це тобі минеться. Тому, оцінюючи ймовірність здійснення загроз, доцільно виходити не тільки із середньостатистичних даних, але враховувати також специфіку конкретних інформаційних систем. Якщо в підвалі будинку, займаного організацією, розташовується сауна, а сам будинок має дерев'яні перекриття, то ймовірність пожеж, на жаль, виявиться істотно вище середнього.

Після того, як накопичені вихідні дані й оцінений ступінь невизначеності, можна переходити до обробки інформації, тобто власне до оцінки ризиків. Цілком припустимо застосовувати такий простий метод, як множення ймовірності здійснення загрози на передбачуваний збиток. Якщо для ймовірності й збитку використовувати трибальну шкалу, то можливих добутків буде шість: 1, 2, 3, 4, 6 й 9. Перші два результати можна віднести до низького ризику, третій і четвертий - до середнього, два останні - до високого, після чого з'являється можливість знову привести їх до трибальної шкали. По цій шкалі й варто оцінювати прийнятність ризиків. Щоправда, граничні випадки, коли обчислювальна величина збіглася із прийнятною, доцільно розглядати більш ретельно через наближений характер результату.

Якщо які-небудь ризики виявилися неприпустимо високими, необхідно їх нейтралізувати, реалізувавши додаткові заходи захисту. Як правило, для ліквідації або нейтралізації уразливого місця, що зробило загрозу реальною, існує кілька механізмів безпеки, різних за ефективністю й вартістю. Наприклад, якщо велика ймовірність нелегального входу в систему, можна зажадати, щоб користувачі обирали довгі паролі (скажемо, не менше восьми символів), задіяти програму генерації паролів або закупити інтегровану систему аутентифікації на основі інтелектуальних карт. Якщо є ймовірність навмисного ушкодження сервера баз даних, що може мати серйозні наслідки, можна урізати замок у двері серверної кімнати або поставити біля кожного сервера по охоронцю.

Оцінюючи вартість засобів захисту, доводиться, зрозуміло, ураховувати не тільки прямі витрати на закупівлю устаткування й/або програм, але й витрати на впровадження новинки й, зокрема, навчання й перепідготовку персоналу. Цю вартість також можна оцінити по трибальній шкалі й потім зіставити її з різницею між обчисленим і припустимим ризиком. Якщо за цього показника новий засіб виявляється економічно вигідним, його можна взяти на замітку (підходящих засобів, імовірно, буде декілька). Однак якщо засіб виявиться дорогим, його не слід відразу відкидати, пам'ятаючи про наближення розрахунку.

Вибираючи підходящий спосіб захисту, доцільно враховувати можливість екранування одним механізмом забезпечення безпеки відразу декількох прикладних сервісів. Так зробили в Масачусетському технологічному інституті, захистивши кілька тисяч комп'ютерів сервером аутентифікації КегЬегоз.

Важливою обставиною є сумісність нового засобу зі сформованою організаційною й апаратно-програмною структурою, із традиціями організації. Заходи безпеки, як правило, носять недружній характер, що може негативно позначитися на ентузіазмі співробітників. Часом збереження духу відкритості важливіше мінімізації матеріальних втрат. Втім, такого роду орієнтири повинні бути розставлені в політиці безпеки верхнього рівня.

Можна уявити собі ситуацію, коли для нейтралізації ризику не існує ефективних і прийнятних за ціною заходів. Наприклад, компанія, що базується в сейсмічно небезпечній зоні, не завжди може дозволити собі будівництво захищеної штаб-квартири. У такому випадку доводиться піднімати межу прийнятного ризику й переносити центр ваги на пом'якшення наслідків і вироблення планів відновлення після аварій, стихійних лих та інших подій. Продовжуючи приклад із сейсмобезпекою, можна рекомендувати регулярне тиражування даних в інше місто й володіння засобами відновлення первинної бази даних.

Як і будь-яку іншу діяльність, реалізацію й перевірку нових регуляторів безпеки варто попередньо планувати. У плані необхідно врахувати наявність фінансових засобів і строки навчання персоналу. Якщо мова йде про програмно-технічний механізм захисту, потрібно скласти план тестування (автономного й комплексного).

Коли заплановані заходи впроваджені, необхідно перевірити їхню дієвість, тобто переконатися, що залишкові ризики стали прийнятними. Якщо це насправді так, виходить, можна спокійно намічати дату найближчої переоцінки. У іншому випадку доведеться проаналізувати допущені помилки й провести повторний сеанс керування ризиками негайно.

Розділ 6. Процедурний рівень інформаційної безпеки

6.1. Основні класи заходів процедурного рівня

Ми приступаємо до розгляду заходів безпеки, які орієнтовані на людей, а не на технічні засоби. Саме люди формують режим інформаційної безпеки, і вони ж виявляються головною загрозою, тому "людський чинник" заслуговує на особливу увагу.

В українських компаніях накопичений багатий досвід регламентування й реалізації процедурних (організаційних) заходів, однак справа в тому, що вони прийшли з "докомп'ютерного" минулого, тому вимагають переоцінки.

Варто усвідомити той ступінь залежності від комп'ютерної обробки даних, у яку потрапило сучасне суспільство. Без усякого перебільшення можна сказати про необхідність інформаційної цивільної оборони. Спокійно, без перебільшення, потрібно пояснювати суспільству не тільки переваги, але й небезпеки, пов'язані з використанням інформаційних технологій. Акцент варто робити не на військовій або кримінальній стороні справи, а на цивільних аспектах, пов'язаних з підтримкою нормального функціонування апаратного й програмного забезпечення, тобто концентруватися на питаннях доступності й цілісності даних.

На процедурному рівні можна виділити наступні класи заходів:

* керування персоналом;

* фізичний захист;

* підтримка працездатності;

* реагування на порушення режиму безпеки; » планування відновлювальних робіт.

6.2. Керування персоналом

Керування персоналом починається із прийому нового співробітника на роботу й навіть раніше - зі складання посадових інструкцій. Уже на даному етапі бажано підключити до роботи фахівця з інформаційної безпеки для визначення комп'ютерних привілеїв, асоційованих з посадою. Існує два загальних принципи, як: варто мати на увазі:

* розподіл обов'язків;

* мінімізація привілеїв.

Принцип розподілу обов'язків пропонує так розподіляти ролі й відповідальність, щоб одна людина не могла порушити критично важливий для організації процес. Наприклад, небажана ситуація, коли великі платежі від імені організації виконує одна людина. Надійніше доручити одному співробітникові оформлення заявок на подібні платежі, а іншому - завіряти ці заявки. Інший приклад - процедурні обмеження дій суперкористувача. Можна штучно "відокремити" пароль суперкористувача, повідомивши першу його частину одному співробітникові, а другу - іншому. Тоді критично важливі дії з адміністрування ІС вони зможуть виконати тільки вдвох, що знижує ймовірність помилок і зловживань.

Принцип мінімізації привілеїв пропонує виділяти користувачам тільки ті права доступу, які необхідні їм для виконання службових обов'язків. Призначення цього принципу очевидно - зменшити збиток від випадкових або навмисних некоректних дій.

Попереднє складання опису посади дозволяє оцінити її критичність і спланувати процедуру перевірки й відбору кандидатів. Що відповідальніше посада, тим ретельніше потрібно перевіряти кандидатів: навести про них довідки, можливо, поговорити з колишніми товаришами по службі й т.д. Подібна процедура може бути тривалою й дорогою, тому немає сенсу додатково ускладнювати її. У той же час, нерозумно й зовсім відмовлятися від попередньої перевірки, щоб випадково не прийняти на роботу людину з карним минулим або психічним захворюванням.

Коли кандидат визначений, він, імовірно, повинен пройти навчання; принаймні, його варто докладно ознайомити зі службовими обов'язками, а також з нормами й процедурами інформаційної безпеки. Бажано, щоб заходи безпеки були ним засвоєні до вступу на посаду й до введення його системного рахунку із вхідним ім'ям, паролем та привілеями.

З моменту введення системного рахунку починається його адміністрування, а також протоколювання й аналіз дій користувача. Поступово змінюється оточення, у якому працює користувач, його службові обов'язки й т.п. Все це вимагає відповідної зміни привілеїв. Технічну складність представляють тимчасові переміщення користувача, виконання ним обов'язків замість співробітника, що пішов у відпустку, і інші обставини, коли спочатку потрібно надати повноваження, а через деякий час обмежити. У такі періоди профіль активності користувача різко змінюється, що створює труднощі при виявленні підозрілих ситуацій. Певної акуратності варто дотримуватися й при видачі нових постійних повноважень, не забуваючи ліквідувати старі права доступу.

Ліквідація системного рахунку користувача, особливо у випадку конфлікту між співробітником та організацією, повинна вироблятися максимально оперативно (в ідеалі - одночасно з повідомленням про покарання або звільнення). Можливе й фізичне обмеження доступу до робочого місця. Зрозуміло, якщо співробітник звільняється, у нього потрібно прийняти все його комп'ютерне господарство й, зокрема, криптографічні ключ?, якщо використовувалися засоби шифрування.

До керівництва співробітниками додається адміністрування осіб, що працюють за контрактом (наприклад, фахівців фірми-постачальника, що допомагають запустити нову систему). Відповідно до принципу мінімізації привілеїв, їм потрібно виділити рівно стільки прав, скільки необхідно, і забрати ці права відразу по закінченні контракту. Проблема, однак, полягає в тому, що на початковому етапі впровадження "зовнішні" співробітники будуть адмініструвати "місцевих", а не навпаки. Тут на перший план виходить кваліфікація персоналу організації, його здатність швидко навчатися, а також оперативне проведення навчальних курсів. Важливі й принципи вибору ділових партнерів.