ТРЕБОВАНИЯ К БЕЗОПАСНОСТИ ПО
Чернова Е.В.
Студентка 3 курса математического факультета, Оренбургский государственный университет
ТРЕБОВАНИЯ К БЕЗОПАСНОСТИ ПО
Аннотация
В статье рассмотрены основные требования к безопасности программного обеспечения, политики безопасности и механизмы, которые обеспечивают соблюдение этой безопасности.
Ключевые слова: политика безопасности, аутентификация, авторизация, аудит, конфиденциальность, целостность, доступность.
Chernova E. V.
3rd year student of the faculty of mathematics of the Orenburg state University
SECURITY REQUIREMENTS FOR
Abstract
The article describes the main requirements for software security, security policies and mechanisms to ensure that this security.
Keywords: security policy, authentication, authorization, auditing, privacy, integrity, availability.
При рассмотрении общих требований для программного обеспечения, которое мы хотим создать, мы должны также учитывать его требования к безопасности. Нормальные требования к ПО это то, что ПО должно делать. Требования безопасности обрисовывают ожидания защиты работы ПО, и эти требования бывают двух видов. Во-первых, существует цели и политики, связанные с безопасностью. Например, политика нашего банковского интернет приложения может быть такой, что баланс банковского счёта должен быть приватным. То есть никакой другой пользователь не смог выяснить ничего об этом без соответствующего разрешения. Во-вторых, чтобы соблюдать безопасность, мы должны иметь требования к механизмам, которые мы используем. Например, можно потребовать, чтобы для аутентификации на основе пароля, пароли были сильными (не менее 8 символов). База данных с паролями не должна быть доступна для любой программы, кроме программы аутентификации логина.
Теперь давайте копнём немного глубже и изучим различные виды политик и механизмы, которые проектировщик может использовать. Существует три классических типа политик безопасности – политика конфиденциальности, целостности и доступности. Политика конфиденциальности иногда подразделяется на неприкосновенность частной жизни и требования анонимности. Обязательные механизмы защиты часто затрагивают три вида деятельности – аутентификация, авторизация и проведение аудита. Давайте рассмотрим каждый из этих элементов более подробно.
Во-первых, мы будем учитывать три вида политик безопасности, начиная с неприкосновенности частной жизни и конфиденциальности. Секретность и конфиденциальность обеспечиваются, если эта важная информация является не доступной для неавторизированных пользователей. Мы, как правило, относим к этому свойства, такие как неприкосновенность частной жизни для физического лица, а так же конфиденциальность данных. Нарушение неприкосновенности частной жизни или конфиденциальности может произойти непосредственно, или может произойти с побочной стороны. Другой тип конфиденциальности политика анонимности. Это особый вид конфиденциальности.
Следующий вид политики безопасности, который мы будем рассматривать, это политика целостности. Идея заключается в том, что чувствительная информация не должна быть повреждена при действиях неавторизированных пользователей. Например, только владелец счета может разрешить снятие средств со своего счета. Если какая-либо другая сторона смогла повлиять на счёт вывода, то это нарушило бы целостность баланса банковского счета. Таким образом, нарушение целостности может быть прямым или косвенным. Например, у нас есть возможность специально снимать деньги со счета, потому что система не правильно разрешает совершать подобные действия. Или, мы можем вводить систему в заблуждение, чтобы достичь своих целей. Например, с помощью межсайтовой подделки запроса.
Третий вид политики безопасности – это доступность. В этом случае, доступность означает, что система реагирует на запросы, которые приходят к ней. Например, мы можем захотеть, чтобы пользователь всегда имел доступ к своему счеты для каких-либо запросов или снятие денег со счёта.
После того, как мы определили политику безопасности для приложения, мы должны думать о том, каким образом будем обеспечивать соблюдение этой безопасности. Лесли Лэмпорт определил золотой стандарт (gold standart), который состоит из трёх механизмов – аутентификации, авторизации и аудита. Рассмотрим первый элемент золотого стандарта – аутентификацию. Цель аутентификации – определить, какими правами будет обладать текущий субъект. В частности, многие политики безопасности требуют понятия идентичности. Для того чтобы разрешить то или иное действие, мы должны знать, кто именно его хочет выполнить (какими правами он обладает). То есть мы должны определить, кто субъект, и будет ли его действие разрешено в соответствии с нашей политикой безопасности. Таким образом, аутентификация пытается ответить на вопрос, кто это и какие у него права. Существует много способов определять, реальный пользователь пытается войти в систему, или же злоумышленник. Наиболее простая проверка – это введение пароля. И если пароль введён корректно, то мы имеем дело с реальным пользователем. Другой подход – использование биометрических данных. Для пользователя-человека мы могли бы проверить сканирование сетчатки или отпечатки пальцев. Иной подход предполагает наличие смартфона у пользователя. То есть в качестве дополнительной проверки пользователь должен ввести либо номер своего телефона, либо код подтверждение, который он получит на телефон. Механизмы аутентификации, которые используют более одного из этих факторов, называются многофакторными методами проверки подлинности.
Следующим элементом золотого стандарта является авторизация. Авторизация определяет, когда принципал может выполнить определённое действие. Например, Ване разрешён доступ к своему собственному счёту, но он не имеет права доступа к счёту Алисы. Существуют самые разнообразные политики безопасности, которые включают некоторые виды авторизаций.
Завершающим элементом золотого стандарта является аудит. Здесь идея состоит в том, чтобы удержать достаточно информации, чтобы иметь возможность определить обстоятельства нарушений, или установить, что эти нарушения не происходят. Такая информация часто хранится в лог-файлах – файлах с записями о событиях в хронологическом порядке. То есть мы должны защитить эти файлы от несанкционированного доступа.
В заключении хочется отметить, что осуществлять требования безопасности нужно в соответствии с целями вашей организации. Вы должны оценить все слабые места в системе, осуществить моделирование потенциальных угроз. Таким образом, вы определяете ресурсы, которые должны защищать. И в дальнейшем определить политику безопасности и механизмы, которые будут направлены на срыв потенциальных угроз.
Литература
- Электронный ресурс: http://its.ucsc.edu/security/training/intro.html
- Электронный ресурс: http://www.consumer.ftc.gov/articles/0009-computer-security
- Электронный ресурс: http://www.kolomna-school7-ict.narod.ru/sthtm
References
- Electronic resource: http://its.ucsc.edu/security/training/intro.html
- Electronic resource: http://www.consumer.ftc.gov/articles/0009-computer-security
- Electronic resource: http://www.kolomna-school7-ict.narod.ru/st30301.htm