Войти в систему
Войти с помощью соц. сетей:
По возможности функции, касающиеся управления системой (администрирования), должны быть изолированы от остальной функциональной части приложения. Таким образом, нарушение функций, не связанных с обеспечением безопасности, не повлияет на управление системой (контроль доступа). Данный совет упоминается в очень надежных руководствах по безопасности: ITSG-33 канадского правительства и Специальной публикации NIST 800-53 S-3.
ПРИМЕЧАНИЕ. Определение из стандарта ITSG-33: информационная система отделяет функциональные возможности пользователя (включая услуги пользовательского интерфейса) от функций управления информационной системой.
Здесь также речь идет о разделении функций, но мы говорим уже об административных возможностях. Если в приложении есть административная часть, то соответствующие функции должны находиться в отдельном объекте либо классе, на другой странице либо панели или в отдельном приложении. Желательно, чтобы администраторы приложения входили в систему с отдельным набором учетных данных (с включенным MFA).
Прежде всего стоит дать определение секретам применительно к программному обеспечению. Когда мы говорим о секретах и управлении секретами, мы не имеем в виду секреты, которые пользователи хранят внутри разрабатываемого программного обеспечения, мы имеем в виду скрытые элементы, используемые программным обеспечением для корректной работы. Имя пользователя и пароль (учетные данные), которые требуются для входа в приложение, являются секретом пользователя. Мы же говорим о секретах, которые компьютерные системы используют для взаимодействия друг с другом.
Когда приложение входит в базу данных, используемая им строка подключения является секретом. Когда веб-сервер включает протокол HTTPS (шифрование) в веб-приложении с помощью сертификата и пары ключей, закрытый ключ для этого сертификата является секретом. Закрытые ключи, API-ключи, хеши, пароли и все остальное, что является конфиденциальным и используется приложением (а не человеком или пользователем), считается секретом.
Ручное управление секретами – ужасная практика, которая отнимает много времени, имеет высокую сложность и чревата ошибками. Именно поэтому были созданы тайники – специальное программное обеспечение, которое управляет секретами и доступ к которому можно получить через приложение, конвейер CI/CD или сервисную учетную запись. Человек не должен иметь доступ к секретам, находящимся в тайнике, кроме тех случаев, когда их необходимо поместить в тайник или обновить либо когда произошла чрезвычайная ситуация. Доступ к тайнику должен тщательно охраняться, а все связанные с ним события – регистрироваться и сопровождаться оповещением.
Хороший тайник обязан предупреждать об истечении срока действия сертификатов и предоставлять подробную информацию о последних изменениях секретов. Некоторые тайники имеют еще больше возможностей. Лучше пользоваться всеми функциями тайника, а не управлять им вручную.
Подделка межсайтовых запросов (CSRF) – это уязвимость, при которой злоумышленник убеждает жертву перейти по ссылке или посетить вредоносный сайт. Ссылка или сайт запускает транзакцию в приложении (допустим, покупку нового модного телевизора, который будет отправлен злоумышленнику), и поскольку пользователь уже вошел в учетную запись (кто не оставляет браузер открытым несколько дней подряд?), уязвимое веб-приложение завершает транзакцию (покупку), о которой пользователь ничего не знает, пока не придет счет. Однако к тому времени уже слишком поздно реагировать. Лучший способ защиты от данной уязвимости – перед каждым важным действием приложения (покупка, деактивация аккаунта, смена пароля и т. д.) запрашивать у пользователя что-то, что может предоставить только он сам: предлагать повторно ввести пароль, ввести капчу или секретный токен, который будет только у него. Наиболее распространенным подходом является использование секретного токена (часто называемого анти-CSRF-токеном). На момент написания книги этот метод защиты настолько распространен, что уже включен во многие современные платформы (такие как. Net, Java и Ruby on Rails). Таким образом, нет необходимости кодировать эту функцию самостоятельно, а следует лишь убедиться в том, что она включена.
СОВЕТ. Пользователи ненавидят капчу. По возможности используйте вместо них невидимые для пользователя анти-CSRF-токены. Применять анти-CSRF-токены вместо того, чтобы заставлять вводить капчу или (повторно) пароль, – значит соблюдать приоритет удобной безопасности.
Производственные данные не должны быть задействованы в тестировании, разработке или любых других процессах, не связанных с бизнесом. В разработке и тестировании используется замаскированный (анонимизированный) набор данных, а в производстве находятся только «настоящие» данные.
Разделение производственных данных означает предоставление доступа к данным меньшему количеству систем (и, следовательно, меньшему количеству людей), что сокращает возможность возникновения внутренних угроз и тем самым уменьшает поверхность атаки.
Ко всему прочему, при разделении сотрудники будут реже подглядывать в личные данные. Представьте ваши ощущения, если бы вы узнали, что сотрудники компании, которая занималась разработкой используемого вами мессенджера, читают ваши сообщения. Это было бы нарушением конфиденциальности и, скорее всего, пользовательского соглашения. Разделение производственных данных устраняет большинство возможностей возникновения такого рода угроз, а если подобная ситуация произойдет, то ее можно будет отследить.
Войти с помощью соц. сетей: