Съдържание
- 1. Справяне с вложени групи
- 2. Преминаване към RBAC от ACL
- 3. Управление на компютри
- Без грешки, без стрес - Вашето стъпка по стъпка ръководство за създаване на софтуер, променящ живота, без да разрушава живота ви
- 4. Работа с блокирането на потребителските акаунти
- 5. Повишаване на разрешението и пълзене на разрешително
Източник: Tmcphotos / Dreamstime.com
За вкъщи:
Научете пет ключови области на AD, които може да изискват софтуерна намеса на трети страни.
По-вероятно дори по-критично за вашето предприятие от най-цененото ви приложение или най-защитената ви интелектуална собственост е вашата Active Directory (AD) среда. Active Directory е централен за сигурността на вашата мрежа, система, потребител и приложения. Той управлява контрола на достъпа за всички обекти и ресурси в рамките на вашата компютърна инфраструктура и на значителни разходи както за човешки, така и за хардуерни ресурси, необходими за управлението му. И благодарение на доставчици на софтуер на трети страни, можете също да добавите Linux, UNIX и Mac OS X системи към репертоара на управлявани ресурси на AD.Управлението на AD за повече от няколко десетки потребители и групи става много болезнено. А основният интерфейс и организацията на Microsofts не помага за облекчаване на тази болка. Active Directory не е слаб инструмент, но има негови аспекти, които оставят администраторите да търсят инструменти на трети страни. Това парче изследва най-важните административни недостатъци на AD.
1. Справяне с вложени групи
Вярвате или не, всъщност има най-добри практики, свързани със създаването и използването на вложени AD групи. Тези най-добри практики обаче трябва да бъдат темперирани от вградени AD ограничения, така че администраторите да нямат право да разширяват вложени групи до повече от едно ниво. Освен това, ограничението за предотвратяване на повече от една вложена група на съществуваща група би предотвратило възникването на бъдещи домакински и административни проблеми.
Внедряването на множество нива на групата и позволяването на множество групи в рамките на групи създава сложни проблеми с наследяването, заобикаля сигурността и разрушава организационните мерки, които управлението на групата е проектирано да предотврати. Периодичните одити на AD ще позволят на администраторите и архитектите да преоценят AD организацията и да коригират вложеното разпространение на групата.
Системните администратори са имали кредото „Управление на групи, а не индивиди“ от години в мозъка им, но управлението на групи неизбежно води до вложени групи и лошо управлявани разрешения. (Научете за сигурността, базирана на ролите на Softerra Adaxes тук.)
2. Преминаване към RBAC от ACL
Преминаването от ориентиран към потребителя списъци за управление на достъпа (ACL) AD стил на управление към по-корпоративния метод за контрол на достъпа, базиран на роли (RBAC) изглежда, че би било лесна задача. Не е така с AD. Управлението на ACL е трудно, но преминаването към RBAC също не е разходка в парка. Проблемът с ACL е, че няма централно местоположение в AD за управление на разрешения, което прави администрацията предизвикателна и скъпа. RBAC се опитва да смекчи разрешенията и грешките на достъпа, като обработва разрешенията за достъп по роля, а не по отделни, но все още не достига поради липсата на централизирано управление на разрешенията. Но колкото и болезнено да е преминаването към RBAC, това е много по-добре от ръчното управление на разрешения на база потребител на потребител с ACL.
ACL се провалят мащабируемост и гъвкаво управление, тъй като те са твърде широки по обхват. Ролите, алтернативно, са по-прецизни, тъй като администраторите предоставят разрешения въз основа на ролите на потребителите. Например, ако нов потребител в информационна агенция е редактор, тогава тя има ролята на редактор, както е дефинирана в AD. Администраторът поставя този потребител в групата редактори, които й предоставят всички разрешения и достъп, които редакторите изискват, без да добавят потребителя към множество други групи, за да получат еквивалентен достъп.
RBAC дефинира разрешения и ограничения въз основа на роля или функция на работа, а не присвояване на потребител на няколко групи, които могат да имат по-широки разрешения. Ролите на RBAC са много специфични и не изискват влагане или други сложни ACL за постигане на по-добри резултати, по-сигурна среда и по-лесно управляема платформа за сигурност.
3. Управление на компютри
Управлението на нови компютри, управление на компютри, които са прекъснали връзката с домейна, и се опитват да направят каквото и да е с компютърните акаунти кара администраторите да искат да се насочат към най-близкия бар Мартини - за закуска.
Без грешки, без стрес - Вашето стъпка по стъпка ръководство за създаване на софтуер, променящ живота, без да разрушава живота ви
Не можете да подобрите уменията си за програмиране, когато никой не се интересува от качеството на софтуера.
Причината за такова драматично твърдение е, че има 11 думи, които никога не искате да четете на екрана като администратор на Windows: „Отношението на доверие между тази работна станция и основния домейн се е провалило.“ Тези думи означават, че сте на път да прекарайте многократни опити и евентуално няколко часа, свързвайки отново тази работна станция с домейна. Жалко е, че стандартната поправка на Microsoft не работи. Стандартното поправяне се състои в нулиране на обекта на акаунта на компютъра в Active Directory, рестартиране на работната станция и пресичане на пръстите. Другите средства за повторно прикачване често са също толкова ефективни, колкото стандартните, което кара администраторите да преиздават прекъснатата система, за да я свържат отново с домейна.
4. Работа с блокирането на потребителските акаунти
Няма корекция за самообслужване за блокиране на акаунта, въпреки че няколко доставчици на софтуер на трети страни са решили проблема. Потребителите трябва да изчакат период от време, преди да изпробват отново, или да се свържат с администратор, за да нулират заключения акаунт. Възстановяването на заключен акаунт не е стрес за администратора, въпреки че може да се окаже смущаващ за потребителя.
Един от недостатъците на AD е, че блокирането на акаунта може да произхожда от източници, различни от потребител, въвеждащ неправилна парола, но AD не дава на администратора никакви намеци за този произход.
5. Повишаване на разрешението и пълзене на разрешително
Има потенциал привилегированите потребители да повишат допълнително привилегиите си, като добавят себе си към други групи. Привилегированите потребители са тези, които имат някои повишени привилегии, но имат достатъчно правомощия да се добавят към допълнителни групи, което им предоставя допълнителни привилегии в Active Directory. Този недостатък на сигурността позволява на вътрешния атакуващ да добавя привилегии поетапно, докато съществува задълбочен контрол върху домейн, включително възможност за блокиране на други администратори. (Елиминирайте ръчните процедури, отнемащи ресурси в Active Directory Identity Management. Научете как тук.)
Попълването на разрешенията е условие, което се случва, когато администраторите не успеят да премахнат потребителите от определена група привилегии, когато работата на потребителя се промени или когато потребителят напусне компанията. Попълването на разрешения може да позволи на потребителите достъп до корпоративните активи, от които потребителят вече няма нужда. Повишаването на разрешението и пълзенето на разрешения създават сериозни опасения за сигурността. Съществуват различни приложения на трети страни, които могат да извършват одити за откриване и предотвратяване на тези условия.
От малки компании до глобални предприятия, Active Directory обработва удостоверяването на потребителите, достъпа до ресурси и управлението на компютъра. Това е един от най-ценените части на мрежовата инфраструктура в бизнеса днес. Колкото е мощен инструмент, колкото Active Directory, той има много недостатъци. За щастие, доставчиците на софтуер извън Microsoft разшириха функциите на Active Directory, разрешиха неговия лошо замислен дизайн на интерфейса за управление, консолидираха неговата функционалност и масажираха някои от по-очевидните му несъответствия.
Това съдържание ви е предоставено от нашия партньор, Adaxes.
