Управление привилегированными учетными записями

  • Tutorial
Привилегированными называют учетные записи, которые дают доступ к системе с очень широкими полномочиями. Например, root в Unix или Administrator в Windows. Логин и пароль для домашнего роутера, с помощью которого делается настройка – это тоже привилегированная учетная запись. Коротко говоря, это такие учетные записи, используя которые можно сделать с системой или устройством (почти) все что угодно. Иногда их называют «ключами от королевства” (keys of the kingdom), ведь они дают возможность получить полный доступ к информации и параметрам работы системы. Используя привилегированный доступ можно сделать что-то полезное, а можно и вредное. Все, как обычно, зависит от того, кто делает и с какой целью.


Зачем управлять?


Если у Вас имеется 3 компьютера, один роутер и скучающий администратор, то никакого особенного управления, скорее всего, не потребуется. Потребность в управлении привилегированным доступом обычно возникает в больших компаниях (например, в банках, страховых компаниях), у которых обширная клиентская база. Информационные системы таких компаний управляют финансовыми и персональными данными, работу с которыми опасно пускать на самотек. Существуют нормативные документы, которые описывают некоторые требования, которым должны соответствовать процессы в организации. В частности, важно обеспечить:
  1. Четкое понимание, кто именно и в какое время мог иметь доступ к системе
  2. Возможность получить информацию, кто именно обращался к системе в определенный момент времени, что он там делал и зачем


Все это нужно, главным образом, для готовности к разбору полетов, если вдруг что-то случится.
Важный момент – ответы на эти вопросы позволяют не только найти виноватого, но и доказать непричастность конкретных людей.



К примеру, в сеть утекла база клиентов банка с их номерами телефонов, адресами и т.п. Есть 10 администраторов, которые, теоретически, могли иметь доступ к базам в любое время суток. В логах видно, что некто под учетной записью Administrator заходил в систему и выполнил копирование базы данных. Но кто именно это был – неизвестно. Более того, в отсутствие явного управления доступом, нельзя с уверенностью утверждать, что это один из этих 10 администраторов. Ведь пароль мог узнать кто-то еще, подслушав разговор, увидев на бумажке или просто подобрав.

Итак, надеюсь, вопрос о том, надо ли управлять привилегированным доступом, уже не возникает.
Перед нами теперь другой вопрос.

Как управлять?


Управление привилегированными учетными записями отличается от управления обычными, персональными учетными записями.

Каждому пользователю информационной системы выдается его персональная учетная запись в системе, для которой назначены необходимые права доступа. Чтобы получить доступ к системе по этой учетной записи нужно знать пароль, управление которым почти целиком находится на совести пользователя. Организация может влиять на этот процесс только косвенно, вводя политики управления паролями, вынуждающие пользователя создавать пароли требуемого уровня сложности и изменять с заданной периодичностью. Предполагается, что пароль кроме пользователя никто не знает, так что если при разборе полетов в протоколах мелькает его имя – то он сам и виноват. Либо в том, что сделал что-то не то, либо в том, что не обеспечил должного усердия по защите своего пароля. Чтобы бороться с кражей пароля применяют многофакторные методы аутентификации, но это уже другая история.

С привилегированными учетными записями ситуация немного другая. Управление привилегированными учетными записями сводится к организации такого процесса, при котором всегда достоверно известно, кто именно и в какой момент времени работал под учетной записью администратора. Как правило, одной и той же учетной записью пользуются сразу несколько человек. При этом, определить, кто именно может знать пароль администратора – достаточно сложно. Люди приходят и уходят, а пароль остается. Для обеспечения контроля необходимо, чтобы в каждый момент времени полный доступ к системе (даже теоретически) имел минимум сотрудников, в идеале – никто.

Таким образом, мы приходим к неожиданному решению: пароли от привилегированных учетных записей раздавать никому не надо. Сотрудник будет получать пароль только на время, когда ему потребуется что-то сделать в системе. А как только он свою работу сделал – пароль меняется и его опять никто не знает. А раз не знает – то и сделать ничего не может, даже теоретически. А чтобы никто не смог подобрать пароль за разумное время, меняется он на что-то неудобоваримое, криптографически сложное и т.п. Алиби администраторам обеспечено (см. выше пример про утечку данных).

На практике такой процесс обычно реализуется одним из двух способов: административный или автоматизированный.

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

Если доступ к системам выполняется часто и многими сотрудниками, а контроль над происходящим терять не хочется, используют автоматизированные системы, которые делают процесс управления привилегированным доступом простым и понятным. Вместо секретного шкафчика пароли хранятся в защищенной базе данных. Сотрудники запрашивают и получают пароли через Web-интерфейс, предварительно войдя в систему под своей персональной учетной записью (для дополнительной защиты может применяться многофакторная аутентификация). По завершении работы (или по истечении определенного периода времени) пароль автоматически изменяется, новый пароль записывается в базу данных и лежит там до следующего использования. Важным преимуществом автоматизированных решений по сравнению с административным методом является возможность быстрого построения отчетов, необходимых при проведении аудиторских проверок.

Вот, собственно, почти все, что можно сказать про управление привилегированными учетными записями. В заключение лишь замечу, что кроме элементарных действий по управлению паролями, такие системы часто обладают целым рядом полезных функций, сильно упрощающих жизнь как администраторам, так и безопасникам. Например, удаленный доступ к системе может предоставляться прозрачным образом, без показа пароля на экране. Система сама, скрыто от пользователя передаст пароль на удаленный компьютер и сразу откроет экран удаленного доступа. Пароль доступа изменится сразу после закрытия сессии. Сессии удаленного доступа могут автоматически записываться в виде видеороликов. Некоторые системы умеют сканировать сеть и автоматически обнаруживать системы и приложения, доступом к которым нужно управлять. Все эти полезные функции являются полезным дополнением к основной задаче – управлению доступом.
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 16

    +2
    Можно хоть какие-то примеры привести софта для автоматизации данного процесса? Практика с сейфом есть, а с софтом — нет, только теория :(
      0
      Конечно можно :). Не хотел чтобы сочли пост рекламой в каком-либо виде.
      Из лидеров рынка я бы выделил ERPM от Lieberman Software и комплексное решение от Cyber-Ark. Есть решения от монстров рынка Identity Management — IBM и Oracle. Они не могут похвастаться большой функциональностью, это лишь дополнения к основным IdM продуктам. Есть нишевые решения, например Hytrust специализируется на защите виртуальных сред.
        0
        Можно добавить Xceedium и Quest
        –1
        Зачем мучать людей веб-интерфейсами и прочими изощренными велосипедами, когда можно сразу использовать многофакторную аутентификацию, включая биометрическую, включить логи, обеспечить их надежное хранение и удобный доступ к ним для аудита? А если человек находится под давлением (терморектальный криптоанализ, семья в заложниках и т.п.), он и при системе «пароли в шкафчике» сможет сделать то, что от него требуют.

        Тут бы разумнее смотрелась система управления правами и шифрование, дающее, скажем, сделать дамп базы, но не позволяющее без разрешения уполномоченным лицом его расшифровать, но ведь администраторам часто требуется доступ к данным на различных уровнях.
          0
          Так все эти «велосипеды» отчасти и придуманы для того, чтобы приладить многофакторную аутентификацию к тем системам, устройствам и т.п., которые сами этого делать не умеют. Я вижу два основных плюса от использования подобных систем:
          1. Строгая аутентификация пользователей, причем для всех систем используется один каталог пользователей.
          2. Централизованный аудит обращения ко всем системам.

          Но я ни в коем случае не буду утверждать, что эти системы нужно обязательно ставить всем и везде. Стоят они не дешево, преимущества, действительно, сходу не очевидны. Так что перед принятием решения о внедрении (или не внедрении) подобных решений, сначала нужно прийти к пониманию почему и зачем это делается.
          +1
          В одной веселой контое видел разделяемые пароли.
          Одна половина пароля у СБ, другая у ИТ. Приходят к терминалу для работы с критичной системой вместе, вводят по очереди свои части, ИТшник работает, СБшник бдит.
            0
            Тоже встречал такой подход (возможно даже в той же самой конторе :-) ), думал, что это вполне нормальная практика, когда:
            1. Для всех штатных операций каждый пользователь имеет персонифицированную учетную запись.
            2. Все не персонифицированные учетные записи имеют разделенный пароль, а каждая часть в свою очередь в сейфе у соответствующего подразделения. После использования пароль меняется.

            Думаю было бы удобно, если как то улучшить эту схему так, чтобы представителям подразделений можно было ввести свою персонифицированную и в сумме они давали права keys of the kingdom.
            0
            Объясните, пожалуйста, зачем вообще привилегированным учетным записям назначать пароли? И потом их героически менять? Разве нет механизма, подобного sudo в unix? Когда юзер всегда логинится под своей личной учетной записью, а потом, если ему это явно разрешено, может с нее переключиться на привилегированную. В этом случае не нужно никаких паролей менять вообще, а давать/отбирать права можно моментально и централизованно.
              0
              Правильно понимаю, что переключившись на привилегированную мы получаем неограниченные привилегии? Тогда что мешает нам сначала слить/изменить/испортить данные и после этого очистить все протоколы доступа и будто бы ничего не было?
                0
                Логи же по сети все отправляются на другую машину, к которой ни у кого, кроме Президента Человечества, нет доступа. Не? И как этот вопрос относится к sudo?
                  0
                  Правильно понимаю, что этот пресловутый Президент Человечества может единолично творить что хочет?

                  Возможно я не до конца понимаю, что делает sudo, предлагаю разобрать на конкретном примере. Не хочу привязываться к ОС, по этому пример такой — есть СУБД Oracle, в ней есть пользователь sys, под которым можно сделать все что угодно, а потом почистить за собой следы. Допустим, там был бы механизм, когда обычный персонифицированный пользователь может написать sudo и получить права sys'а, как это остановит его от последующей зачистки следов? А когда пароль разделен, а части в конвертах по сейфам, то подобный инцидент возможен только в случае сговора нескольких лиц.

                  И да, такие учетные записи не предназначены для постоянного использования, только для каких либо исключительных ситуаций. Если же возникает потребность в их регулярном использовании, то значит имеются проблемы в системе прав/ролей персонифицированных учетных записей.
                0
                sudo — один из механизмов предназначенных для решения проблемы.
                Но увы, не везде есть и применим. И всегда кому то надо хранить самый главный пароль, тобы потом починить то, что натворили пользователи из wheel :)
                  0
                  Хранить — не значит выдавать всем и менять его каждую минуту. Самый главный пароль требуется лишь в самых экстренных случаях, которые происходят 1-2 раза за все время жизни компании. Топик явно не о нем. Я просто правда не понимаю то, что описано в топике и потом так яростно и на полном серьезе обсуждается в комментариях — что, реально кто-то раздает кому-то вот такие главные пароли «из сейфа» и потом их меняет, кладет в сейф и т.д.? Зачем? О том и вопрос.
                    0
                    В топике усложнено, но пример с разделяемым паролем выше — я видел. Но там системка такая, что по одному не работают.
                    И пусть самый главный пароль требуется 1 раз в год, им все равно надо управлять и иметь механизм его защиты.
                  0
                  Так вся эта кухня для того и придумана. В идеальном случае человек входит в систему под личной учеткой, потом приходит на специальную веб-страничку и говорит: «дай ка мне доступ к серверу ABCDEF». И ему сразу открывается терминал в эту систему.
                  Пароли в данной ситуации — это только средство предоставить ему доступ.
                    0
                    Это хорошо в том случае, когда система позволяет управлять своими учётками ИЗВНЕ (что для корпоративного зоопарка редкость). Также лично видел систему в которой нельзя было иметь иметь более двух администраторов. (смысл?)

                Only users with full accounts can post comments. Log in, please.