ВКР. Горынин ВКР 2022. Исследование и анализ объекта автоматизации 4 1 Описание предприятия 4

• Название: Исследование и анализ объекта автоматизации 4 1 Описание предприятия 4
• Дата: 05.07.2022
• Размер: 6.55 Mb.
• Имя файла: Горынин ВКР 2022.docx
• Тип: Исследование; #624999
• страница: 6 из 11

2.5 Обеспечение информационной безопасности

Основными способами защиты от несанкционированного доступа к объектам информационных систем являются:

• 
  идентификация и аутентификация пользователей информационных систем и активизированных ими процессов;
  
• 
  авторизация субъектов (определение прав доступа субъекта к объекту с конфиденциальной информацией);
  
• 
  аудит событий, имеющих отношение к безопасности информационной системы.
  

Администратор базы данных в системе может создать и затем редактировать список пользователей, которым разрешена работа с системой. При добавлении нового пользователя указывается следующие свойства создаваемой учетной записи (на вкладке «Основные»):

• 
  имя, под которым пользователь будет зарегистрирован в системе;
  
• 
  полное имя (ФИО, должность);
  
• 
  пароль пользователя, ввод которого потребуется для его идентификации средствами системы;
  
• 
  подтверждение пароля пользователя (требуется для исключения возможности ошибки при вводе пароля, т.к. символы пароля при вводе заменяются символами *);
  

Требования к авторизации:

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

Требования к обработке и хранению информации:

• 
  Хранение паролей должно осуществляться в хэшированном виде с использованием стойких алгоритмов хеширования.
  
• 
  Хранение программных токенов, использующихся в веб-приложениях, допустимо только в виде постоянных cookie с флагами httpOnly и secure.
  
• 
  URL-адреса API не должны раскрывать конфиденциальную информацию, такую как ключи, токены сеанса и т.д.
  
• 
  Хранение конфиденциальной информации в логах разрешено только в маскированном виде
  
• 
  Вся обрабатываемая информация, полученная с клиентской стороны должна быть валидирована и санитизирована, включая все заголовки. Количество ожидаемых параметров должно проверяться на соответствие с количеством переданных с клиентской стороны.
  
• 
  Например, в случае использования XML, должна проводиться валидация по XSD схеме.
  
• 
  Сервисы должны иметь средства защиты от перебора аутентификационных данных (брутфорса)
  
• 
  Сервисы должны проверять http заголовок "Content-type" на ожидаемый тип данных
  

Требования к сетевой сегментации:

• 
  Сервера баз данных и сервера приложений не должны размещаться в одном сегменте сети для разделения слоев логики и данных.
  
• 
  Информационная система не должна размещаться в сегменте сети, в котором размещены рабочие станции
  
• 
  Сетевой доступ для сервера должен быть ограничен минимально необходимым набором IP адресов или доменных имен, протоколов и портов.
  
• 
  Критичность информационной системы должна соответствовать критичности инфраструктуры
  

Требования по организации интеграции:

• 
  Интеграции между системами допускаются по REST, SOAP, GraphQL или с помощью очередей сообщений. Файловые межсистемнвые интеграции допустимы только в случае невозможности организации передачи сообщений вышеуказанными способами
  
• 
  Запрещено использовать стандартный заголовок User-Agent. Для интеграции необходимо использовать User-agent с названием сиcтемы.
  
• 
  При использовании протоколов FTP, SFTP, SMTP и подобных протоколов при реализации межсистемных интеграций должна обеспечиваться возможность контроля целостности файлов при передаче между отправляющей и принимающей информационной системой. Файлы, не прошедшие проверку целостности, к обработке не принимаются. Контроль целостности должен быть реализован при помощи: Проверка подлинности с помощью симметричного алгоритма HMAC с использованием алгоритма хэширования SHA2
  
• 
  В принимающей системе должны быть реализованы ограничения: на тип (расширение) принимаемых файлов; на длину имени загружаемого файла; на размер загружаемого файла; на запрещенные символы в имени файла.
  

Требования к процессу разработки:

• 
  Должны существовать по крайней мере три отдельные среды: среда разработки, среда тестирования и продуктивная среда.
  
• 
  Доступ к исходному коду, средам и документации должен быть ограничен в соответствии с принципом минимально необходимых привилегий
  
• 
  Тестовые данные не должны содержать реальные данные клиентов
  
• 
  Учетные данные, такие как пароли, строки подключения к базе данных или токены API, не должны использоваться совместно между средой разработки, тестирования и продуктивной средой
  
• 
  Запрещено использовать криптографические алгоритмы и криптографические библиотеки собственной разработки
  
• 
  Все сторонние компоненты, используемые приложениями, такие как библиотеки и фреймворки, должны быть идентифицированы и проверены на наличие известных уязвимостей с помощью сканера зависимостей
  
• 
  Должны быть установлены заголовки безопасности
  
• 
  Идентификаторы, полученные из токена пользователя, должны иметь приоритет над идентификаторами, на которые можно повлиять
  
• 
  Изменения в исходном коде должны выполняться на сервере приложений, а не в базе данных. Например, запрещена реализация бизнес-логики на SQL процедурах. Требование необходимо с точки зрения разделения словев логики и данных. 
  
• 
  Приложения не должны запускаться от имени учетных записей, которые имеют административные права с высокими привилегиями
  
• 
  Только персонализированные учетные записи должны использоваться для управления исходным кодом в системе контроля версий
  

Требования к CI/CD:

• 
  Для систем сборки и развертывания должны использоваться разные агенты. Использование общего (shared) агента для разных информационных систем запрещено.
  
• 
  Секреты (пароли, SSH-ключи, токены, сертификаты), используемые в системе сборки, релизах и системе развертывания, не должны храниться в открытом виде.
  
• 
  Любое изменение в релизных ветках на стороне системы хранения кода должно сопровождаться рецензированием как минимум двумя разными разработчиками.
  
• 
  Любое изменение кода, образа или артефакта - это новая версия прикладного ПО, которая требует полного прохождения процессов CI/CD.
  
• 
  Запрещено ручное развертывание релизов в промышленную среду.
  
• 
  При формировании артефакта должны использоваться библиотеки, пакеты и образы, которые получены только из централизованной системы хранения артефактов. Скачивание зависимостей напрямую из сети Интернет запрещено.
  

Требования к заголовкам безопасности.

• 
  Заголовок X-Frame-Options следует использовать в обязательном порядке для всех видов запросов. Директивы заголовка контролируют встраиваемость страницы в теги frame, iframe и тд. Помогает предотвратить clickjacking.
  

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

Заголовок может использовать следующие директивы: 

DENY - страница не может быть использована в тегах frame, iframe;

SAMEORIGIN - страница может быть помещена в теги frame, iframe и т.д. только на тех страницах, за исключение кросс-доменных запросов;

Allow-From URI - разрешает встраивать страницу в страницы с доменами указанными в “URI”. Данная директива считается устаревшей и не поддерживается в современных браузерах.

• 
  Заголовок HTTP Strict-Transport-Security (HSTS) также является при выполнении всех запросов.
  

Заголовок обязует браузер подключаться к серверу по HTTPS.

Использует следующие директивы:

Strict-Transport-Security: max-age=SECONDS - количество секунд, в течение которых браузер обязан подключаться к серверу только по HTTPS;

Strict-Transport-Security: includeSubDomains - браузер должен также подключаться к поддоменам по https.

Обе директивы можно использовать вместе одновременно.

Пример корректного использования заголовка выглядит следующим образом: Strict-Transport-Security: max-age=31536000; includeSubDomains

• 
  Referrer-Policy является обязательным заголовком и рекомендуется к проставлению во всех типах запросов.
  

Директивы заголовка определяют какую информацию и в каких случаях надо поместить в заголовок Referrer при переходе из одной страницы на другую.

Возможные директивы для использования:

no-referrer	заголовок Referrer не будет подставляться в запросы;
no-referrer-when-downgrade	Referrer не будет подставляться в запрос в случае понижения безопасности соединения (https → http, https → file). В остальных случаях заголовок будет содержать полный URL вместе с GET параметрами;
origin	Referrer будет подставляться всегда и будет содержать только ORIGIN;
origin-when-cross-origin	при переходе на ресурс с одинаковым Origin в Referrer будет помещаться весь URL запроса вместе с GET параметрами. В случае перехода на другой домен referrer будет содержать только origin;
same-origin	При переходе на другой домен или на http с https referrer подставляться не будет. А в остальных случаях будет подставляться полный URL;
strict-origin	Referrer не будет подставляться в запрос при понижении безопасности соединения (https → http, https → file). В остальных случаях заголовок будет содержать только ORIGIN;
strict-origin-when-cross-origin	Полный URL вместе с GET параметрами подставляется в referrer при переходе из одного ресурса на другой с одинаковыми ORIGIN. Referrer не будет подставляться в запрос в случае понижения безопасности соединения. В остальных случаях будет содержать origin;
unsafe-url	Referrer с полным URL подставляется во все запросы.

Пример корректного использования заголовка: Referrer-Policy: no-referrer или Referrer-Policy: strict-origin-when-cross-origin

Пример некорректного использования заголовка: Referrer-Policy: unsafe-url;

Referrer-Policy: no-referrer-when-downgrade;

Если заголовка Referrer-Policy не будет в ответе от сервера, то заголовок Referrer будет подставляться по правилам директивы no-referrer-when-downgrade.

• 
  Следующим обязательным заголовком является X-Content-Type-Options.
  

Заголовок предназначен только для отключения MIME-снифинга у браузера. Если ответ от сервера будет содержать Content-Type заголовок со значением application/json, а тело запроса будет содержать html, то браузер не будет пытаться интерпретировать тело, как обычную html страницу, а будет пытаться распарсить json.   

Заголовок может использовать только одну директиву:  nosniff - отключает у браузера MIME-снифинг. Т.е. браузер не будет стараться угадать тип данных, передаваемых в ответе

• 
  Рекомендуется использовать заголовок Clear-Site-Data, но не является обязательным, строгим требованием к безопасности.
  

Заголовок обязует браузер пользователя очищать хранилище, указанное в заголовке: cache - локальный кеш; cookies - куки;

Лучше всего использовать данный заголовок при логауте пользователя со следующими директивами: Clear-Site-Data: "cache","cookies","storage","executionContexts".

• 
  Обязательно использовать заголовок Content-Type не только в сервисах, вызываемых браузерами, но и при выполнении межсервисрных интеграций.
  

Обязательность использования заголовка также объясняется требованием безопасности к отключению автоматического распознавания типа контента, переданного в сообщении.

Заголовок указывает MIME - тип данных, передаваемых в теле ответа. 

Заголовок должен содержать значение, совпадающее с типом данных, передаваемых в ответе от сервера. Например, в случае отправки клиенту png картинки, заголовок должен быть установлен в значение image/png.
Пример заголовков из ответа сервиса можно наблюдать на рисунке. В примере ответа представлен запрос методу /decision, описанному в пункте 2.4 настоящей работы.



Как видно из ответа сервиса, рекомендованные заголовки успешно внедрены в решение. Рекомендации по внедрению желательных заголовков также выполнены, о чем можно судить по HEADER: x-Content-Type-Options.