♦ Правильные методы идентификации и авторизации (система логинов и паролей). Пароли обязательно должны быть «стойкими», то есть состоять из 6–8 символов – букв в разном регистре с использованием цифр и пересылаться только в зашифрованном виде, а количество попыток авторизации на сайте должно быть ограничено
♦ Использование шифрования и системы цифровых подписей при передаче конфиденциальной информации. В качестве метода шифрования обычно используется SSL и особый протокол передачи данных – не HTTP, а HTTPS
♦ Защита от всех известных на данный момент угроз . Прежде всего, это угрозы клиенту сайта – формирование обманных HTTP-запросов: подмена содержимого сайта, межсайтовое выполнение сценариев, расщепление HTTP-запроса
...
Какая угроза к нам придет – та от рук сисадмина и «погибнет»!
Требования к программно-аппаратной платформе
♦ Использование последних стабильных версий серверного программного обеспечения
♦ Размещение на сервере только программного обеспечения, необходимого для работы сайта (минимальная правильная конфигурация сервера)
♦ Безопасная настройка всех сервисов , защищающая от распространенных угроз
♦ Установка необходимых и достаточных прав на файлы и директории на веб-сервере
♦ Защита папок от просмотра содержимого
Требования к администрированию сайта
♦ Наличие системы технического аудита (журналирование событий на всех уровнях системы: операционной системы сервера, веб-сервера, системы управления сайтом и базы данных), а также информационного аудита – для отслеживания событий, связанных с безопасностью информации
♦ Наличие системы создания резервных копии системы для быстрого развертывания системы на другом сервере в случае, если в результате отказа веб-системы от какой-либо угрозы она не может быть восстановлена быстро с используемого сервера
Человеческий фактор
Несмотря на огромное количество видов и типов технических угроз, основную опасность для сайта представляют люди, управляющие им. До 98 % проблем возникает из-за их некомпетентности или банальной безответственности команды поддержки. Это самая сложноустранимая угроза, справиться с которой не всегда позволяют даже сертификация персонала и введение регламентов поддержки.
87. Тестовая версия
...
Тестовая версия сайта – это копия внешнего («боевого») сайта, создаваемая с целью опробования различных нововведений (например, изменения дизайна страниц, введения новых функциональностей и т. д.). Часто она размещается в локальной сети компании.
Важность создания тестовой версии часто недооценивается. В результате целый ряд новых идей по модернизации сайта может отклоняться в силу страха перед внесением изменений непосредственно на внешний сайт.
...
Только у тестовой версии есть право на ошибку!
Тестовая версия снимает эти опасения, а также позволяет более гибко согласовывать все нововведения. Например, новая версия баннера может быть размещена вначале на тестовой версии, согласована с отделом маркетинга и только после этого вынесена на внешний сайт.
...
Из разговора программистов: «Ну, ты перенеси изменения с девелопмента на продакшн и протестируй в реале»
Таким образом, вы можете использовать тестовую версию сайта для решения следующих задач:
♦ Тестирование новых идей
♦ Обучение редакторов, публикаторов, менеджеров, дизайнеров и программистов
♦ Внедрение новых функциональностей и сервисов
♦ Видоизменение дизайна сайта и/или отдельных его страниц
88. Резервные копии
...
Резервное копирование (Backup) – необходимая и самая надежная мера защиты сайта, уменьшающая угрозу его потери в результате сбоев оборудования, умышленных или неумышленных действий пользователей, форс-мажорных обстоятельств и т. д.
Обычно резервное копирование проводится для следующих видов информации:
♦ Статическая информация в файловой системе (неизменяющиеся файлы, «постоянный» контент, программные файлы)
♦ Конфигурация системного программного обеспечения (файлы настроек операционной системы, веб-сервера и т. д.)
♦ Динамическая информация в базах данных (информация, находящаяся под управлением СУБД)
♦ Служебная информация (логи)
Наибольшую ценность представляет динамическая информация, которая должна копироваться регулярно, как правило, раз в день. Статическая информация обновляется редко и обычно резервируется по факту изменения. Логи наименее значимы, их копирование не является обязательным.
Временная информация в файловой системе (кэш, файлы с результатами промежуточных вычислений и т. п.) не требуют резервирования.
Для осуществления копирования необходимо выбирать периоды времени, в которые нагрузка на сайт минимальна. Обычно это ночное время, когда создание резервной копии может происходить в автоматическом режиме.
Виды резервирования
Существует несколько стандартных видов резервирования, которые могут быть применены на вашем корпоративном сайте:
♦ Метод отображающего дублирования диска
♦ Дифференциальное резервирование
♦ Полное резервирование
♦ Пофайловый метод
♦ Добавочное резервирование
О том, какой из методов резервирования используется на вашем сайте, важно поинтересоваться у хостинг-провайдера.
Проблема непротиворечивости резервной копии
Проблема непротиворечивости резервных копий возникает, если процесс резервного копирования идет параллельно с функционированием сайта и изменением на нем копируемой информации.
В результате информация в резервной копии и на сайте может быть логически не согласована . Решают эту проблему одним из следующих способов:
♦ Запрещение на время резервного копирования действий, вызывающих изменение динамической информации
♦ Использование специальных утилит , обеспечивающих непротиворечивость информации
Управление резервными копиями
Для защиты резервных копий рекомендуются следующие действия:
♦ Резервные копии должны быть максимально защищены и физически выведены из-под воздействия факторов основной системы (то есть, как минимум, храниться на другом жестком диске и, желательно, в другом городе)
