Корпоративный веб-сайт на 100%. Требуйте от сайта большего! - Роман Овчинников

♦ Правильные методы идентификации и авторизации (система логинов и паролей). Пароли обязательно должны быть «стойкими», то есть состоять из 6–8 символов – букв в разном регистре с использованием цифр и пересылаться только в зашифрованном виде, а количество попыток авторизации на сайте должно быть ограничено

♦ Использование шифрования и системы цифровых подписей при передаче конфиденциальной информации. В качестве метода шифрования обычно используется SSL и особый протокол передачи данных – не HTTP, а HTTPS

♦ Защита от всех известных на данный момент угроз . Прежде всего, это угрозы клиенту сайта – формирование обманных HTTP-запросов: подмена содержимого сайта, межсайтовое выполнение сценариев, расщепление HTTP-запроса

Какая угроза к нам придет – та от рук сисадмина и «погибнет»!

Требования к программно-аппаратной платформе

♦ Использование последних стабильных версий серверного программного обеспечения

♦ Размещение на сервере только программного обеспечения, необходимого для работы сайта (минимальная правильная конфигурация сервера)

♦ Безопасная настройка всех сервисов , защищающая от распространенных угроз

♦ Установка необходимых и достаточных прав на файлы и директории на веб-сервере

♦ Защита папок от просмотра содержимого

Требования к администрированию сайта

♦ Наличие системы технического аудита (журналирование событий на всех уровнях системы: операционной системы сервера, веб-сервера, системы управления сайтом и базы данных), а также информационного аудита – для отслеживания событий, связанных с безопасностью информации

♦ Наличие системы создания резервных копии системы для быстрого развертывания системы на другом сервере в случае, если в результате отказа веб-системы от какой-либо угрозы она не может быть восстановлена быстро с используемого сервера

Человеческий фактор

Несмотря на огромное количество видов и типов технических угроз, основную опасность для сайта представляют люди, управляющие им. До 98 % проблем возникает из-за их некомпетентности или банальной безответственности команды поддержки. Это самая сложноустранимая угроза, справиться с которой не всегда позволяют даже сертификация персонала и введение регламентов поддержки.

87. Тестовая версия

Тестовая версия сайта – это копия внешнего («боевого») сайта, создаваемая с целью опробования различных нововведений (например, изменения дизайна страниц, введения новых функциональностей и т. д.). Часто она размещается в локальной сети компании.

Важность создания тестовой версии часто недооценивается. В результате целый ряд новых идей по модернизации сайта может отклоняться в силу страха перед внесением изменений непосредственно на внешний сайт.

Только у тестовой версии есть право на ошибку!

Тестовая версия снимает эти опасения, а также позволяет более гибко согласовывать все нововведения. Например, новая версия баннера может быть размещена вначале на тестовой версии, согласована с отделом маркетинга и только после этого вынесена на внешний сайт.

Из разговора программистов: «Ну, ты перенеси изменения с девелопмента на продакшн и протестируй в реале»

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

♦ Тестирование новых идей

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

♦ Внедрение новых функциональностей и сервисов

♦ Видоизменение дизайна сайта и/или отдельных его страниц

88. Резервные копии

Резервное копирование (Backup)  – необходимая и самая надежная мера защиты сайта, уменьшающая угрозу его потери в результате сбоев оборудования, умышленных или неумышленных действий пользователей, форс-мажорных обстоятельств и т. д.

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

♦ Статическая информация в файловой системе (неизменяющиеся файлы, «постоянный» контент, программные файлы)

♦ Конфигурация системного программного обеспечения (файлы настроек операционной системы, веб-сервера и т. д.)

♦ Динамическая информация в базах данных (информация, находящаяся под управлением СУБД)

♦ Служебная информация (логи)

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

Временная информация в файловой системе (кэш, файлы с результатами промежуточных вычислений и т. п.) не требуют резервирования.

Для осуществления копирования необходимо выбирать периоды времени, в которые нагрузка на сайт минимальна. Обычно это ночное время, когда создание резервной копии может происходить в автоматическом режиме.

Виды резервирования

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

♦ Метод отображающего дублирования диска

♦ Дифференциальное резервирование

♦ Полное резервирование

♦ Пофайловый метод

♦ Добавочное резервирование

О том, какой из методов резервирования используется на вашем сайте, важно поинтересоваться у хостинг-провайдера.

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

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

В результате информация в резервной копии и на сайте может быть логически не согласована . Решают эту проблему одним из следующих способов:

♦ Запрещение на время резервного копирования действий, вызывающих изменение динамической информации

♦ Использование специальных утилит , обеспечивающих непротиворечивость информации

Управление резервными копиями

Для защиты резервных копий рекомендуются следующие действия:

♦ Резервные копии должны быть максимально защищены и физически выведены из-под воздействия факторов основной системы (то есть, как минимум, храниться на другом жестком диске и, желательно, в другом городе)