Аутентификация (AuthN)

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

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

Существуют несколько вариантов.

1. Воспользоваться уже существующим интернет-сервисом от третьей стороны. Канадское налоговое агентство использует банковские идентификаторы для проверки канадцев при уплате налогов. Многие социальные сети в интернете позволяют пройти верификацию с помощью учетных данных из Twitter, LinkedIn, Facebook, Google или Microsoft.

Плюсы

– Очень быстрая реализация.

– Нет ответственности за сопровождение или тестирование кода.

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

– Некоторые пользователи могут больше доверять такому подходу или считать его более удобным.

Минусы

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

– Некоторые пользователи могут не иметь учетной записи ни на одном из перечисленных сторонних ресурсов.

– Использование такого сервиса может быть сопряжено с определенными расходами.

– Чаще всего такие сервисы собирают личную информацию и метаданные пользователей. Взлом сторонней системы повлияет на ваш сайт.

2. Приобрести или найти бесплатную библиотеку или программную систему, которая станет частью вашей системы и будет выполнять функции идентификации.

Плюсы

– Реализуется быстрее, чем разработка собственной системы.

– Ответственность возлагается не за проектирование системы, а только за реализацию.

– Некоторые клиенты предпочитают размещать данные у вас.

Минусы

– Использование такой системы может быть сопряжено с определенными расходами.

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

– Размещение данных подразумевает ответственность за них.

3. Написать собственную систему аутентификации с нуля.

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

Авторизация (AuthZ)

Под авторизацией подразумевается определение того, к чему пользователь может или не может получить доступ в системе, а управление доступом предоставляет (или запрещает) такой доступ. Разрешено ли Алисе просматривать документы другой команды? Может ли Боб удалить другого пользователя из системы, находящейся под его управлением? На подобные вопросы отвечают авторизация и управление доступом.

Наиболее популярной методикой определения доступа является управление доступом на основе ролей (англ. Role Based Access Control, RBAC). Она подразумевает, что «чей-либо доступ определяется на основании назначенной ему в системе роли». Можно быть чьим-нибудь начальником на своем рабочем месте, но иметь обычный доступ к системе, в то время как подчиненный сотрудник может иметь права администратора, поскольку именно эту роль он выполняет в системе (то есть является администратором).

Давайте немного углубимся в эту тему на примере Алисы и Боба.

Когда Алису впервые повысили до уровня руководителя, она была очень рада получить больше привилегий и полномочий. В ее распоряжении были счет для расходов, право подписи на сумму $50 000 и офис на верхнем этаже. Однажды Алиса обнаружила в системе управления документами компании каталог документов, доступ к которым ей был запрещен, что неприятно ее удивило. В IТ-отделе ей объяснили, что в данном каталоге находится реестр рисков и доступ к нему имеет только служба IТ-безопасности и начальник отдела информационной безопасности (англ. Chief Information Security Office, CISO). Доступа не было даже у генерального директора: информацию в сжатом виде она получала от CISO. Алисе пояснили также, что у нее нет служебной необходимости в этой информации, а в системе управления документами ее учетной записи не была назначена роль «Операции по обеспечению безопасности», поэтому ей не могут предоставить доступ. Для добавления этой роли необходимо получить разрешение CISO, так как она не входит в структуру службы безопасности. Алису устроил такой ответ. Она лишь хотела понять причину ограничения данной части системы для нее и попросила не заморачиваться с открытием доступа.

ПРИМЕЧАНИЕ. Реестр рисков – это документ, в котором указаны все известные риски для организации. Данная информация имеет высокий уровень конфиденциальности и, оказавшись в чужих руках, может нанести компании огромный ущерб. Такой документ, в котором описаны все слабые места организации, может стать отличным оружием для любого злоумышленника.

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

В прошлом году Боб руководил проектом по созданию нового бухгалтерского программного обеспечения. В его команду входили Сара (тестировщик программного обеспечения), Эмили (разработчик программного обеспечения) и Дженнифер (администратор базы данных, DBA). Все они играли разные роли в проекте и в своей компании, поэтому им требовались разные разрешения и доступы. Эмили не нужен доступ владельца базы данных (англ. Database Owner, DBO), однако ей определенно не обойтись без прав DBA. Бобу, как руководителю проекта, никогда не требовался доступ к веб-серверу или базе данных, поэтому он не запрашивал эти права в системе.

Когда нужно было определить, кому какой доступ предоставить, Боб попросил дать ему права обычного пользователя, чтобы он мог видеть работу приложения, а для своей команды он запросил следующее.

• Для тестировщика программного обеспечения (Сары): регулярный доступ к приложению, а также возможность запускать все инструменты автоматизации тестирования на своем компьютере. Ей также был необходим доступ на запись к программному обеспечению DevOps Pipeline, чтобы она могла добавлять тесты в конвейер.

• Для разработчика программного обеспечения (Эмили): доступ к приложению, доступ к среде разработки, возможность создавать и запускать хранимые процедуры в базе данных разработки, а также разрешение запускать DevOps Pipeline, но не вносить в него изменения.

• Для администратора базы данных (Дженнифер): доступ к серверу базы данных на уровне владельца базы данных. Но она остается без доступа к веб-серверу, конвейеру и даже коду. Дженнифер ничего из этого не нужно, поэтому соответствующий запрос не был сделан.

В начале проекта Эмили хотела иметь больше прав на сервере базы данных, веб-сервере и конвейере, ведь кто, будучи разработчиком программного обеспечения, не хотел бы иметь доступ ко всему? Однако ее роль в проекте стала причиной отказа.

Сотрудник службы безопасности объяснил, что предоставление доступа только к необходимым системам усилило защиту проекта, так как, если компьютер Эмили будет взломан, заражен вирусом-вымогателем или любым другим вредоносным ПО, злоумышленник будет ограничен ролью и доступом, которые она имела к различным системам. Эмили с неохотой, но согласилась с этим доводом.

В этой проектной ситуации RBAC чрезвычайно полезен. Системный администратор может легко назначить соответствующие роли каждому из членов проекта Боба и тем самым гарантировать, что им разрешен доступ только к тому, что необходимо для работы. Системный администратор просто зашел в свою систему каталогов, назначил каждому члену команды соответствующую роль и добавил их в ресурсы проекта.

Использование ролей вместо предоставления отдельного доступа для каждого человека вручную особенно полезно в ситуациях, когда кто-то меняет команду, работу или уходит из организации. Простое изменение роли и перенаправление группы (команды) внутри организации позволяет удалять и добавлять все необходимые доступы. Не рекомендуется управлять доступом вручную – это шаг к возникновению ошибок, которые могут привести к инцидентам безопасности.

Существуют три широко распространенные модели управления доступом:

• избирательное управление доступом (англ. Discretionary Access Control, DAC);

• мандатное управление доступом (англ. Mandatory Access Control, MAC);

• управление доступом на основе разрешений (англ. Permission Based Access Control, PBAC).

Избирательное управление доступом (DAC) означает, что владелец информации, системы или ресурсов может предоставлять и удалять доступ по своему усмотрению другим лицам, использующим ту же систему идентификации (например, пользователям одной сети, членам одного сайта по обмену фотографиями и т. д.).

После рождения первого внука Боб сделал сотни фотографий, которые позже загрузил в свое облачное онлайн-хранилище. В тот момент система давала ему возможность предоставить определенным пользователям системы доступ к его фотографиям. Боб предоставил доступ к фотографиям всем своим родственникам, добавляя их по одному через имена пользователей (адреса электронной почты). Родственники Боба начали использовать хранилище, чтобы делиться друг с другом семейными фотографиями. Несколько лет спустя кто-то из родственников развелся, и Боб вспомнил, что он предоставил каждому доступ на чтение и запись к своей папке. Он принял решение лишить доступа бывшего члена семьи, просто на всякий случай.

В отличие от управления доступом на основе ролей на работе Боба, когда кто-то меняет роль, системы DAC не обновляются. Они основаны на идентификации в системе, а не роли.

Мандатное управление доступом (MAC) предоставляет доступ к информации и системам на основе уровня чувствительности ресурса и одобрения пользователя, пытающегося получить к нему доступ.

Например, у Алисы нет сверхсекретного допуска, а у Боба есть, поэтому в такой системе Боб сможет получить доступ ко всему, вплоть до сверхсекретных систем и данных. Алисе же такой доступ не предоставляется. У нее есть только публичный доступ, то есть она может получить доступ только к публичным записям.

MAC обычно используется для систем, требующих чрезвычайно высокого уровня обеспечения безопасности. Например, для правительственных военных систем или наборов данных.

Управление доступом на основе разрешений (PBAC) основано на разрешениях. Пользователям предоставляются определенные разрешения на информацию и использование системы. Когда пользователь пытается получить доступ к чему-либо в системе, механизм управления доступом проверяет, было ли ему предоставлено разрешение. Типами разрешений могут выступать READ, WRITE, CREATE, UPDATE, DELETE, PRINT, REBOOT и т. д.

После развода родственников Боб решил изменить систему управления доступом к своим фотографиям. Он предоставил всем READ и WRITE, но только у него были права DELETE и UPDATE.