Кто отвечает за предоставление доступа и надежное предоставление услуг?
Ваши ПРД должны устанавливать, кто отвечает за предоставление разрешения на доступ к вашим службам. Более того, должно быть определено, какой тип доступа они могут предоставлять. Если вы не контролируете, кто дает разрешение на доступ к вашим АС, вы не контролируете, кто использует ваши АС. Контроль за тем, кто имеет право давать доступ, позволит также вам узнать, кто имел или не имел разрешение на доступ при последующих проблемах с защитой.
Существует много схем, которые можно использовать для управления распределением доступа к вашим службам. Далее приводятся факторы, которые вы должны учитывать при определении того, кто распределяет доступ к вашим службам:
- Будете вы управлять предоставлением доступа из одного места или дадите это право нескольким местам?
У вас может быть одно центральное место для предоставления полномочий на доступ в распределенной системе, в которой различные ведомства независимо отвечают за предоставление полномочий на доступ. Нужен компромисс между защищенностью и удобством. Чем более это процесс централизован, тем более он защищен.
- Какие методы вы будете использовать для регистрации новых пользователей и прекращения доступа?
С точки зрения безопасности вам нужно знать механизм, который будет использован при регистрации новых пользователей. При самом незащищенном варианте люди, которые отвечают за регистрацию пользователей, могут просто войти в систему и создать нового пользователя вручную или с помощью механизма, определенного производителем. В общем случае эти механизмы доверяют человеку, запускающему их, и человек, запускающий их, обычно имеет большие привилегии. Если вы выбрали этот способ, вам нужно выбрать кого-либо, кто не подведет вас при решении этой задачи. Другим способом будет создание интегрированной системы, которая запускается людьми, отвечающими за регистрацию, или самими пользователями. Помните, что даже наличие самого защищенного средства создания новых пользователей не избавляет вас от возможности злоупотреблений им.
У вас должны быть разработаны специфические процедуры для добавления новых пользователей в АС. Эти процедуры должны быть хорошо документированы для предотвращения неоднозначных толкований и уменьшения числа ошибок. Уязвимость защиты при создании новых пользователей возникает не только из-за возможных злоупотреблений, но также из-за возможных ошибок. Просто и хорошо документированная процедура поможет быть уверенным, что ошибок не будет. Вы также должны быть уверены, что люди, которые исполняют эти процедуры, понимают вас.
Предоставление полномочий пользователю на доступ к АС - один из самых уязвимых моментов. Вы должны быть уверены, что пароль, выбранный вначале, не может быть легко угадан. Вы должны избегать использования в качестве начального пароля слова, производного от имени пользователя, являющегося частью имени пользователя, или некоторого алгоритмически сгенерированного пароля, который может быть легко угадан. Кроме того, вам не следует позволять пользователям продолжать использовать начальный пароль неопределенно долгое время. Если это возможно, вы должны заставлять пользователей менять начальный пароль при первом сеансе работы с АС. Учитывайте то, что некоторые пользователи могут так никогда и не войти в АС, что делает их пароли уязвимыми неопределенно долгое время. Некоторые организации приняли решение удалять пользователей, которые никогда не пользовались АС, и заставлять владельцев этих имен заново регистрироваться в списке пользователей.