Федеральное государственное автономное образовательное учрежение высшего образования

 

177 

(запрет  доступа  извне,  доступ  только  для  сервера  приложения); 

шифрование 

хранимой 

в 

базе 

данных 

информации; 

использование  безопасных  и  стабильных  версий  сервера 

приложений 

и 

постоянный 

мониторинг 

обновлений; 

использование  только  безопасных  и  рациональных  подходов  к 

разработке приложения (избегание SQL-инъекций, небезопасных 

подключений ресурсов и т.п.); обеспечение целостности данных; 

обязательная  аутентификация  пользователей;  логирование 

действий  пользователей;  гарантия  только  авторизованного 

доступа и т.д. 

Каждый  из  перечисленных  пунктов  представляет  собой 

целое  направление,  которое  можно  развернуть  в  достаточно 

большой  подробный  список  более  конкретных  требований. 

Рассмотрим некоторые из этих направлений чуть более детально.  

Одним  из  часто  используемых  вариантов  приложений 

являются web-сервисы. Отметим некоторые требования, которые 

относятся  именно  к  безопасности  web-сервисов.  Среди  них 

можно выделить несколько групп. 

Требования,  предъявляемые  к  архитектуре  web-сервисов  с 

точки  зрения  вопросов  безопасной  работы  сервиса:  архитектура 

доступных  извне  веб-служб  должна  быть  основана,  по  крайней 

мере,  на  двух  уровнях  безопасности;  основные  функции 

безопасности  для  доступных  извне  веб-служб  должны  быть 

реализованы в ДМЗ и, в зависимости от критичности, обеспечены 

с 

помощью 

Web 

Service 

Security 

Gateway.  

Заметим, что ДМЗ - демилитаризованная зона, есть сегмент сети, 

содержащий  общедоступные сервисы и  отделяющий  их  от 

частных.  В  качестве  общедоступного  может  выступать, 

например, веб-сервис:  обеспечивающий  его сервер,  который 

физически  размещён  в  локальной  сети,  должен  отвечать  на 

любые  запросы  из  внешней  сети,  при  этом  другие  локальные 

ресурсы  необходимо  изолировать  от  внешнего  доступа.  Web 

Service  Security  Gateway  –  это  некоторое  расширение  к 

протоколу SOAP,  которое  предназначено  для  обеспечения 

безопасности web-сервисов. 

Не  менее  важными  являются  вопросы  безопасности 

контента,  с  которым  работает  и  который  предоставляет  web-

сервис.  Если  данные  высокой  конфиденциальности  в  терминах 

стандарта  PCI  DSS  (например,  данные  кредитных  карт,  данных 

 

178 

клиентов  и  пароли  клиентов)  обрабатываются  web-сервисом,  то 

эти данные должны быть надежно защищены в индивидуальном 

порядке  с  помощью  механизмов  на  уровне  приложений,  как, 

например,  с  использованием  XML-шифрования. PCI  DSS 

(Payment  Card  Industry  Data  Security  Standard)-  это  стандарт 

безопасности данных в индустрии платёжных карт, который был 

разработан  Советом  по  стандартам  безопасности  индустрии 

платежных карт (Payment Card Industry Security Standards Council, 

PCI 

SSC) 

и 

учреждён 

несколькими 

международными платёжными 

системами: Visa, 

MasterCard, American Express, JCB и Discover. Этот стандарт есть 

совокупность  12  детализированных  требований,  касающихся 

обеспечения безопасности данных о держателях платёжных карт. 

Такие  данные  передаются,  хранятся  и  обрабатываются  в 

информационных  инфраструктурах  организаций.  Принятие 

соответствующих мер по обеспечению соответствия требованиям 

стандарта 

подразумевает 

комплексный 

подход 

к 

обеспечению информационной  безопасности данных  платёжных 

карт. Запрос к web-сервису должен быть защищен от возможного 

воздействия,  когда  он  передается  через  общественные, 

небезопасные  транспортные  маршруты.  Такое  требование 

подразумевает комплексный подход к решению вопроса и может 

включать  как  использование  SSL,  так  и  применение 

дополнительного шифрования передаваемых данных. 

Безусловным  требованием  безопасной  работы  web-сервиса 

является  аутентификация  при  работе  с  web-сервисом.  Однако 

наличие  аутентификации,  как  таковой,  еще  не  является  залогом 

безопасной  работы  web-сервиса.  К  аутентификации  также 

предъявляется следующий ряд требований: 

1.

 

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

аутентифицированы  надлежащим  образом  до  начала  отправки 

конфиденциальной информации. 

2.

 

Механизм аутентификации отправителя запроса к web-

сервису  должен  быть  основан  на  сильных  криптографических 

алгоритмах с использованием соответствующих фреймворков. 

3.

 

Получатель  запроса  от  web-сервиса  должен  быть 

аутентифицирован отправителем запроса. 

4.

 

Когда  в  целях  безопасности  в  запросе  к  web-сервису 

были  использованы  XML-подписи,  данные  этой  подписи  не 

 

179 

могут  быть  удалены  из  запроса  с  помощью  промежуточного 

обработчика. 

Имеются  также  и  требования  к  работе  с  определенными 

структурами  данных.  Например,  к  работе  с  SOAP  и  XML  также 

предъявляются требования, имеющие отношение к безопасности. 

В  случае, если  SOAP-запрос или  SOAP-ответ обрабатывается не 

сразу  и  должен  быть  помещены  в  буфер  в  ДМЗ, 

конфиденциальность  и  целостность  этого  сообщения  в  буфере 

должны  быть  гарантированы.  Новый  созданный  web-сервис 

должен  использовать  обязательную  схему  XML  для  контента  и 

выполнять 

обязательную 

проверку 

формата. 

Элемент 

SOAPAction  из  HTTP  заголовка  ни  в  коем  случае  не  может 

использоваться  web-сервисом  в  качестве  решения  вопросов 

обеспечения безопасности. 

Немаловажным  является  и  правильное  описание  работы 

самого  web-сервиса.  Для  этих  целей  используют  WSDL  –  Web 

Services  Description  Language  —  язык  описания  web-сервисов  и 

доступа  к  ним,  основанный  на  языке  XML[4].  Не  удивительно, 

что и к WSDL предъявляется ряд требований. Каждый элемент и 

каждый  атрибут,  предоставленный  web-сервисом,  должны 

соответствовать  описанию  и  иметь  значение  в  ожидаемом  типе 

данных,  иметь  ожидаемую  длину  и  соответствовать  описанному 

формату.  Определения  работы  web-сервиса  не  должны 

использовать 

какие-либо 

неограниченные 

или 

не 

специфицированные  атрибуты.  Все  запросы  к  web-сервису 

должны  быть  провалидированы  на  стороне  web-сервиса  в 

соответствии  с  подробной  спецификацией  WSDL,  которая 

описывает этот запрос. Если web-сервис не содержит формальной 

спецификации  входных  данных,  он  должен  быть  защищен 

использованием  белого  и  черного  списков  для  «незаконных» 

символов,  передающихся  на  web-сервис.  Если  использование 

белого  и  черного  списков  не  представляется  возможным,  сам 

web-сервис  должен  быть  защищен  от  возможных  атак 

проникновения.  Это  означает,  что  он  должен  быть  в  состоянии 

корректно обработать неправильно отформатированный входные 

данные.  Только  наименьшее  возможное  число  API  функций  на 

стороне  web-сервиса  могут  быть  предоставлены  в  открытый 

доступ.  

API  –  интерфейс  программирования  приложений,  интерфейс 

 

180 

прикладного  программирования  –  Application  Programming 

Interface  ‒  набор  готовых  классов,  процедур,  функций, 

предоставляемых  приложением  или  операционной  системой  для 

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

Работа  практически  любого  web-приложения  не  обходится 

без  коммуникации  с  базой  данных.  В  ней  сохраняют  большие 

объемы данных, как «обычных», так и конфиденциальных. Даже 

если  данные  не  являются  конфиденциальными,  их  потеря  или 

повреждение  приведут  к  некорректной  работе  приложения. 

Поэтому  вопросы  безопасности  баз  данных  также  должны 

рассматриваться с высоким приоритетом. 

Среди общих требований к безопасности баз данных можно 

отметить  следующие.  Используемое  программное  обеспечение 

базы  данных  должно  быть  рекомендовано  и  выпущено 

производителем  для  использования  в  production  системах.  Базы 

данных,  создаваемые  по  умолчанию  в  системе  базы  данных, 

должны  быть  удалены  после  выхода  системы  в  production. 

Пользователи,  создаваемые  по  умолчанию,  ровно  как  и  роли  по 

умолчанию,  должны  быть  удалены.  Только  один  экземпляр 

системы  базы  данных  может  быть  установлен  на  экземпляр 

операционной  системы.  Тут  стоит  заметить,  что  чаще  речь  идет 

об  одном  экземпляре  базы  данных  в  смысле  уникальности.  В 

высоконагруженных 

системах 

поднимаются 

несколько 

экземпляров  баз  данных,  между  которыми  настраивается 

репликация  данных.  Такой  подход  позволяет  произвести 

балансировку и распределить нагрузку на несколько баз. Пароли 

по  умолчанию  в  системах  баз  данных  должны  быть  изменены. 

Все  сервисы  базы  данных  должны  быть  поставлены  на  уровне 

операционной  системы  по  принципу  наименьших  привилегий. 

Все сервисы базы данных не могут быть запущены с root правами 

или  с  какими-либо  другими  правами  администратора  в 

операционной  системе.  Не  нужные,  дополнительные  SQL-

функции  (такие  как  T-SQL,  PL  /  SQL,  SQL  PL,  расширенные 

хранимые  процедуры)  и/или  пакеты  должны  быть  удалены  из 

базы данных. Функции базы данных, которые позволяют доступ к 

файлам  операционной  системы  следует  исключить.  Функции 

базы  данных,  которые  позволяют  доступ  к  другим  сетевым 

сервисам  (таким  как  SMTP,  HTTP,  SNMP,  FTP  и  т.д.)  должны 

быть удалены. Функции базы данных, которые дают возможность 

 

181 

доступа к уровню операционной системы или сетевых сервисов, 

должны  быть  лишены  права  доступа  для  ролей  и  групп 

пользователей с  общим доступом.  Права операционной системы 

для  файлов  и  индексов  базы  данных  должны  быть  назначены 

исключительно  для  учетной  записи  операционной  системы  в 

системе базы данных. 

Особо стоит отметить требования к доступу к базам данных: 

доступы  к  базам  данных  между  различными  системами  баз 

данных  должны  осуществляться  в  соответствии  с  принципом 

наименьших  привилегий;  доступы  к  базам  данных  между 

различными  системами  баз  данных  должны  осуществляться  с 

помощью различных учетных записей пользователей. 

Менее  очевидным,  но  не  менее  важным  аспектом 

безопасности  web-приложения  является  мониторинг  системы.  В 

большинстве случаев, именно благодаря грамотно настроенному 

и  правильно  исполненному  мониторингу  и  логированию  в 

системе  удается  быстро  определить  причину  сбоя  в  работе 

системы  и  устранить  ее.  Общие  требования  к  мониторингу 

системы выглядят примерно так: доступы к системам баз данных, 

а  также  критические  процедуры  в  базе  данных  и  обращение  к 

содержимому  базы  данных  должны  быть  тщательным  образом 

логированы;  над  важными  службами  базы  данных  и 

экземплярами 

базы 

должен 

выполняться 

непрерывный 

мониторинг 

относительно 

сценариев 

неправильного 

использования. 

Как  и  для  самого  web-приложения,  так  и  для  базы  данных 

важным моментом является аутентификация. Ниже перечислены 

некоторые требования, предъявляемые к ней. Когда пользователь 

получает  доступ  к  конфиденциальным  данным  через  web-

приложение,  он  должен  пройти  проверку  подлинности  с 

помощью  явного  подтверждения  подлинности  пользователя  в 

соответствии  с  конкретной  учетной  записью  с  именем 

пользователя и с подходящим методом аутентификации (если это 

применимо  в  соответствии  с  имеющимися  ограничениями 

доступа).  Каждый  вход  в  системы  и  каждое  изменение  в 

приложении 

должно 

быть 

гарантировано 

только 

для 

аутентифицированных 

пользователей. 

Аутентификация 

пользователя из другого приложения должна быть осуществлена 

с помощью PKI-инфраструктуры, если она доступна. PKI – Public 

 

182 

Key  Infrastructure  –  инфраструктура  открытых  ключей  —  набор 

средств  (технических,  материальных,  людских  и  т.  д.), 

распределённых  служб  и  компонентов,  в  совокупности 

используемых для поддержки криптозадач на основе закрытого и 

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

нескольких  приложений  должна  быть  выполнена  через 

центральную  систему,  чтобы  достичь  соблюдения  принципов 

SSO.  

SSO – Single Sign-On – технология единого входа — технология, 

при  использовании  которой  пользователь  переходит  из  одного 

раздела  портала  в  другой  без  повторной  аутентификации. 

Ненужные,  неактивные  или  больше  не  используемые  учетные 

записи 

пользователей 

должны 

быть 

заблокированы 

автоматически. 

В  отдельную  группу  можно  выделить  требования,  которые 

предъявляются  к  аутентификации  паролем.  Может  показаться, 

что это относительно простой вопрос. Однако к нему чаще всего 

предъявляют большое количество требований. При вводе пароля 

в соответствующее поле, символы должны заменяться, например, 

на  символ  *.  После  определенного  числа  неудачных  попыток 

входа  в  систему  (количество  попыток  должно  быть 

конфигурируемой 

величиной; 

стандартное, 

наиболее 

распространенное значение – пять), дальнейшие попытки входа в 

систему  должны  быть  заблокированы  или  ограничены 

посредством  запрета  доступа  учетной  записи  на  определенное 

время  (выбор  периода  блокировки  оставляют  за  владельцем 

системы).  В  системе  должна  быть  реализована  возможность 

разблокировать  учетную  запись  пользователя.  Пользователь 

должен  быть  проинформирован  о  критериях  назначения  пароля 

(выбор пароля, качество пароля, проверка надежности пароля) и 

восстановления  пароля.  Если  пользователь  обрабатывает 

конфиденциальную  информацию  своей  учетной  записи  или 

использует 

функциональные 

возможности, 

связанные 

с 

безопасностью,  то  нередким  является  требование  повторной 

аутентификация  до  предоставления  таких  возможностей. 

Возможность завершить сеанс работы с системой должна иметься 

в  любой  части  системы.  Чаще  всего  это  хорошо  различимая 

кнопка.  Пароли  должны  удовлетворять  как  минимум  трем  из 

следующих  условий:  содержать  строчные  буквы,  заглавные 

 

183 

буквы,  цифры  и  специальные  символы.  Пароль  должен  быть 

длиной  не  менее  некоего  числа  символов.  Наиболее 

распространенным является требование длинны не менее восьми 

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

пользователю в любое время. Процедура создания нового пароля 

должна 

сопровождаться 

отображением 

информации 

о 

надежности  вводимого  пароля.  Система  должна  предлагать 

пользователю  изменить  пароль  по  истечению  определенного 

числа календарных дней. Эта величина определяется владельцем 

системы.  Рекомендуемое  число  дней  –  не  более  90.  Смена 

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

случае  M2M  взаимодействия.  M2M  (Machine-to-Machine)  – 

межмашинное  взаимодействие  является  общим  названием 

технологий,  которые  позволяют  машинам  обмениваться 

информацией  друг  с  другом,  или  же  передавать  её  в 

одностороннем  порядке.  Система  должна  проверять  и 

гарантировать,  что  новый  пароль,  вводимый  пользователем, 

отличается  от  предыдущего.  Более  того,  не  редким  является 

требование,  чтобы  новый  пароль  не  совпадал  с  несколькими 

предыдущими  паролями  (обычно  не  более  10).  Для  этого  в 

системе  хранится  история.  Изменение  пароля  должно 

осуществляться  путем  ввода  существующего  пароля  и  ввода 

нового пароля дважды. Учетные записи в системе не могут быть 

созданы  без  пароля,  с  пустым  паролем  или  с  помощью 

стандартного  пароля.  После  первого  входа  в  систему  с 

начальным  паролем,  пользователь  должен  быть  вынужден 

немедленно создать новый личный пароль. Если первоначальный 

пароль,  который  был  отправлен  в  электронном  виде  при 

регистрации,  был  сгенерирован  системой,  то  он  должен  терять 

свою силу не позднее чем через некое фиксированное количество 

часов  после  его  создания.  Рекомендуемая  величина  –  24  часа. 

Регистрационные  процессы  пользователя  в  системе  должны 

гарантировать,  что  эти  действия  не  могут  быть  выполнены  с 

помощью  машин.  В  этих  целях  чаще  всего  используют  такие 

дополнения, как, например, captcha. В случае, когда пользователь 

забыл свой пароль или учетная запись была заблокирована из-за 

слишком  большого  числа  неудачных  попыток  входа  в  систему, 

должен быть реализован автоматический процесс сброса пароля, 

уровень  безопасности  которого  не  ниже,  чем  использование 

 

184 

обычной процедуры входа в систему. Категорически запрещается 

оставлять 

в 

коде 

приложения 

какие-либо 

данные 

пользовательских  учетных  записей  (логины,  пароли  и  т.п.).  В 

системах,  которые  хранят  пользовательские  пароли,  подобная 

информация  обязательно  должна  храниться  в  зашифрованном 

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

необходимость  хранения  паролей  на  устройствах,  с  которых 

выполняется  доступ  в  систему,  то  такое  хранение  должно 

выполняться  с  использованием  средств  безопасности  системы 

этих устройств. 

Одним из  способов  обеспечения безопасной коммуникации 

является  использование  сертификатов.  К  ним  предъявляют 

следующие  требования.  Сертификаты,  как  на  сервере,  так  и  на 

клиенте,  должны  соответствовать  известным  стандартам.  В 

качестве одного из таких стандартов можно рассматривать X.509. 

Он  является  стандартом  ITU-T  для  инфраструктуры  открытых 

ключей  (PKI)  и  управления  привилегиями  (PMI).  X.509 

определяет  форматы  данных  и  процедуры  распределения 

открытых  ключей  с  помощью  сертификатов  с  цифровыми 

подписями. 

Эти 

сертификаты 

предоставляются 

удостоверяющими  центрами.  Такое  понятие,  как  размер  ключа 

сертификата 

также 

является 

немаловажным 

вопросом. 

Рекомендуемый  размер  ключа  –  не  менее  2048  бит.  Не  менее 

важным  является  период  валидности  сертификата.  Не 

рекомендуется делать сертификат более чем на 2 года. 

Среди  общих  требований,  предъявляемых  к  серверу 

приложений,  можно  выделить  следующие.  Доступ  к  серверу 

приложений  ограничивается  списком  определенных  IP  адресов. 

Доступ  с  любого  другого  IP  адреса  строго  запрещен.  Сервер 

приложений  должен  работать  под  выделенной  от  операционной 

системы  учетной  записью,  которая  имеет  только  те  права, 

которые  необходимы  для  функционирования  данного  сервера. 

Нередким  является  требование  единственной  активной  сессии 

для  учетной  записи.  Согласно  этому  требованию,  для  учетной 

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

данный  момент  времени.  Любая  попытка  войти  в  систему  под 

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

должна быть пресечена. При этом предупреждающее сообщение 

должно быть показано пользователю. Сервер приложений должен 

 

185 

использовать  разные  TCP  порты  для  администрирования  самого 

сервера  и  для  приложений,  запущенных  под  этим  сервером. 

Создание  нового  экземпляра  приложения,  работающего  под 

сервером  приложений,  допускается  только  администратором 

сервера  приложений.  На  сервере  приложений  обязательно 

должна  быть  настроена  функциональность  логирования 

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

Вполне очевидно, что логирование для самих приложений также 

является  необходимым  условием.  Для  сервера  приложений 

обязательным 

требованием 

является 

применение 

соответствующих  настроек  конфигурации,  которые  позволяют 

снизить риск отказа работы сервера в случае атак. 

Остановимся 

более 

подробно 

на 

требованиях, 

предъявляемых  к  web-серверу.  Web-сервер  должен  быть 

единственным  сервисом  системы,  который  доступен  извне,  если 

только  он  не  используется  для  администрирования  самой 

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

таким  образом,  что  динамическое  увеличение  контента  внутри 

сервера не будет влиять на работоспособность и качество работы 

сервера.  В  случае,  когда  устойчивость  и  надежность  работы 

приложения 

осуществляется 

посредством 

создания 

и 

функционирования 

нескольких 

экземпляров 

данного 

приложения,  то  обязательным  требованием  является  работа 

каждого  экземпляра  на  отдельном  окружении.  То  есть,  на 

отдельном  физическом  сервере  и  под  управлением  разных 

операционных  систем.  Для  каждого  экземпляра  приложения  не 

обязательна  работа  с  особыми  системными  привилегиями.  В 

целях  обеспечения  безопасности  и  исключения  непредвиденных 

и  несанкционированных  действий,  требуется  отключать  все 

ненужные  и  неиспользуемые  расширения  и  компоненты  web-

сервера.  Ненужные  и  неиспользуемые  HTTP  методы  должны 

быть  деактивированы  на  web-сервере.  В  случае,  когда  на  web-

сервере  используется  CGI,  он  должен  быть  сконфигурирован  с 

учетом 

всех 

требований 

безопасности.  

CGI  –  Common  Gateway  Interface  –  общий  интерфейс  шлюза  ‒ 

стандарт  интерфейса,  используемого  для  связи  внешней 

программы с веб-сервером. Если на web-сервере активирован SSI, 

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

деактивирована.  SSI  (Server  Side  Includes)  –  включения  на 

 

186 

стороне  сервера  ‒  это  несложный  язык  для  динамической 

«сборки» веб-страниц на сервере из отдельных составных частей 

и  выдачи  клиенту  полученного  HTML-документа.  Реализован  в 

веб-сервере  Apache  при  помощи  модуля  mod_include.  В  случае, 

когда  на  web-сервере  используется  WebDAV,  он  должен  быть 

сконфигурирован  с  учетом  всех  требований  безопасности. 

WebDAV  –  Web  Distributed  Authoring  and  Versioning  или  просто 

DAV  ‒  набор  расширений  и  дополнений  к  протоколу  HTTP, 

поддерживающих  совместную  работу  пользователей  над 

редактированием  файлов  и  управление  файлами  на  удаленных 

веб-серверах. Права доступа к файлам, которые содержат данные, 

требующие повышенной защиты, как, например, пароли, должны 

быть  ограничены  до  минимального  размера.  Права  доступа  к 

конфигурационным  файлам  должны  быть  ограничены  до 

минимума.  Данные,  которые  создавались  в  web-сервере,  как 

данные по умолчанию, должны быть удалены. Права на запись в 

выполняемые  файлы,  которые  могут  быть  запущены  с  правами 

администратора,  должны  быть  ограничены  и  доступны, 

соответственно,  только  для  администраторов.  Возможность 

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

Информация  о  web-сервере,  которая  передается  в  HTTP-

заголовках,  должна  быть  максимально  минимизирована. 

Информация  о  web-сервере,  которая  отображается  на  страницах 

ошибок,  должна  быть  максимально  минимизирована.  Ненужные 

настройки  и  назначения  для  неиспользуемых  типов  файлов 

должны  быть  удалены.  Все  конфигурации  web-сервера, 

связанные с неавторизированным доступом, обязательно должны 

быть 

деактивированы. 

Для 

обеспечения 

безопасности 

передаваемых  данных  стоит  использовать  такие  протоколы,  как 

HTTPS, 

SSL, 

TLS.  

Напомним,  что  HTTPS  (HyperText  Transfer  Protocol  Secure) 

является  расширением  протокола  HTTP,  поддерживающее 

шифрование.  Данные,  передаваемые  по  протоколу  HTTPS, 

«упаковываются»  в  криптографический  протокол  SSL  или  TLS.  

SSL  (Secure  Sockets  Layer),  означающий  уровень  защищённых 

сокетов,  -  криптографический  протокол,  который  подразумевает 

более  безопасную  связь.  Он  использует  асимметричную 

криптографию 

для 

аутентификации 

ключей 

обмена, 

симметричное шифрование для сохранения конфиденциальности, 

 

187 

коды  аутентификации  сообщений  для  целостности  сообщений. 

TLS  (Transport  Layer  Security)  ‒  безопасность  транспортного 

уровня,  как  и  его  предшественник  SSL  есть  криптографический 

протокол, обеспечивающие защищённую передачу данных между 

узлами в сети Интернет. TLS-протокол основан на спецификации 

протокола  SSL  версии  3.0.Заметим,  что  не  редким  требованием 

является полная деактивация протокола HTTP  

Перечисленные требования к безопасности web-приложений 

стоит  рассматривать  как  лишь  часть  большого  списка 

требований.  С  развитием  технологий  и  увеличением  списка 

известных уязвимостей, этот список постоянно пополняется. 

Одним  из  важных  моментов  в  безопасности  приложения 

является  полноценное  и  грамотное  тестирование.  Если 

безопасность  действительно  критична,  заказчик  понимает  ее 

важность и располагает некоторыми финансовыми ресурсами, то 

использование  услуг  специализированных  профессиональных 

компаний, которые проводят полномасштабную и всестороннюю 

проверку  безопасности  –  это  наиболее  рациональное  и 

правильное решение. 

Разработка действительно безопасного приложения является 

очень  трудоемким  процессом,  требующим  ответственного 

отношения  всех  участников  разработки,  постоянного  контроля 

качества и соблюдения протоколов безопасности. 

 

Литература 

 

1.

 

Иванов  С.В.,  Москалева  Ю.П.  Разработка  бизнес-приложений  // 

Ученые записки ТНУ, Экономика и управление – 2011 – Том 24 (63). №1. 

‒

 

С. 54-59 

2.

 

Hildenbrand,  Tobias  and  Heinzl,  Armin  and  Geisser,  Michael  and 

Klimpke,  Lars  and  Acker,  Thomas  "A  Visual  Approach  to  Traceability  and 

Rationale Management in Distributed Collaborative Software Development" In: 

Heinzl, Armin and Dadam, Peter and Kirn, Stefan and Lockemann, Peter (eds): 

Lecture  Notes  in  Informatics,  P-151,  PRIMIUM  -  Process  Innovation  for 

Enterprise Software, Koellen, Mannheim – 2009 – pp. 161-178. 

3.

 

Иванов С.В., Москалева Ю.П. Подготовка документации бизнес-

приложений  //  Ученые  записки  ТНУ,  Экономика  и  управление  –  2011  – 

Том 24 (63). №2. 

‒

 С. 49-55 

 

 

 

188 

жүктеу/скачать 5,2 Mb.

Достарыңызбен бөлісу: