Аудит от независимых экспертов

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


 

 
 
 

Обеспечение безопасности веб-проектов

Обеспечение безопасности веб-проектов
Сайт или проект — это веб-приложение, работающее на серверном программном обеспечении операционной системы и использующее её сервисные функции. Управление сайтами идет с компьютеров администратора и пользователей, наделенных данной функцией, имеющими свои операционные системы и программы, а, соответственно, и уязвимости.

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

Основы безопасности информационной среды Web-сервера
Обеспечение безопасности информационной среды сервера — это сложная и ответственная задача. Для её обеспечения с более высоким уровнем необходимо решать эту задачу в комплексе.

Основными моментами этого комплекса являются:
  • доверить выполнение этой задачи своему хостинг-провайдеру или дата-центру;
  • регулярно мониторить защищенность информационной среды Web-сервера с помощью специальных средств;
  • проводить проверку безопасности с помощью проведения независимого комплексного аудита.

Основы безопасности CMS-системы управления веб-проектом
Для безопасности кодов CMS-системы управления проектов используется несколько алгоритмов. Я предлагаю рассмотреть самый оптимальный и наиболее распространенный, который придерживается следующей архитектуры безопасного Web-приложения:
  • одна система входа и авторизации;
  • одинаковый, в сущности, бюджет для каждого пользователя;
  • разноуровневое ограничение прав для доступа;
  • независимая система контроля за доступом от бизнес-логики страниц;
  • обязательное шифрование информации при приеме и передаче;
  • постоянное обновление;
  • ведение журналов отчета;
  • соблюдение политики работы с внешними и переменными данными;
  • применение методики двойного контроля за критически опасными участками кода.

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

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

Обеспечение безопасности сторонних веб-приложений
Что такое стороннее веб-приложение? Это, например, поставленный на сайт дополнительный форум или блок от стороннего производителя, прикрепленный к Вашему сайту. Эта сторонняя составляющая не объединяется с кодами вашей CMS-системы управления сайтом в единую архитектуру, что в свою очередь, становится одной из дополнительных проблем при эксплуатации веб-проекта.

Стороннее веб-приложение следует рассматривать как отдельный подпроект в проекте, следовательно, задача обеспечения безопасности этих веб-приложений соответствует тем же методикам и приемам, которые были изложены выше.

Восстановление Web-ресурса после устранения уязвимостей
Огромное количество организаций в определенных обстоятельствах встречаются с победной компрометацией хостов в своей сети. Одним из первых шагов в восстановлении является создание и документирование всех политик и процедур в ответ на первое вторжение до следующего. Ответные процедуры обязаны очерчивать все действия, которые требуются в ответ на успешную компрометацию сайта, и прописывать последовательность всех действий. Эти процедуры обязаны содержаться в политике безопасности компании.

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

1. Информировать об инциденте руководство.

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

3. Сделать анализ проникновения, включая:

- модификации, произведенные в программном обеспечении и конфигурации;

- модификации, произведенные в данных проекта;

- технические средства или данные, оставленные нарушителями;

- все данные из системных логов, включая определение проникновения и файлы логов firewall.

4. Произвести восстановление системы двумя возможными способами:

- установить чистые операционные системы, приложения, нужные patches и содержимое сервера;

- восстановить из backup’а.

При этом:

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

- произвести применение всех patches;

- произвести изменение всех паролей (даже на нескомпрометированных хостах);

- произвести переконфигурацию всех элементов сетевой безопасности (например, firewall, роутер, IDS) для возможного обеспечения оповещения и доп. защиты.

5. Снова присоединить проект к сети.

6. Провести тесты системы в целях гарантированной безопасности.

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

8. Обязательно документировать все действия.

Вот какие параметры должен рассмотреть системный администратор для принятия решения о переустановке операционной системы или же достаточно будет восстановить всё из backup’а:
  • анализ уровня доступа, который получил нарушитель (например, root, user, guest, system);
  • анализ атакующего по типу (внутренней или внешний);
  • цель атаки (изуродовать веб-страницу, получить доступ к программному обеспечению, платформе для выполнения других атак);
  • определить метод компрометации сайта и системы;
  • определить действия, атакующего после компрометации (например, просмотр отчетов об обнаружении или просмотр логов);
  • какая была продолжительность компрометации;
  • компрометации на сеть (например, количество скомпрометированных хостов).

Если о нарушителе и его действиях мало информации, то необходимо, в любом случае переустанавливать программное обеспечение на хосте.

В заключение хочу сказать, уважаемые разработчики и администраторы веб-проектов, постарайтесь беречь свой труд и потраченные нервы. Надеюсь, моя статья поможет Вам сберечь своё творение от всякой нечисти, блуждающей по сети.

 
Голосов: 4
Баллы рейтинга: 13

Елена Решедько пишет:
11.06.2011 12:03
Писать о безопасности должны только люди, действительно в ней разбирающиеся.

Шерлок, Вы зачем эту тему выбрали? Видно же, что Вы в ней не шарите!
Феликс пишет:
11.06.2011 12:45
Nikolavna, если бы совсем не шарил, не написал статью. А если есть вопросы задавай.
У меня пока вопросов нет.
Елена Решедько пишет:
11.06.2011 12:52
Есть такой вид деятельности - рерайтинг называется. "Взял готовую статью и пересказал своими словами".++

Сделать рерайт статьи - совсем не одно и то же, что написать самому.
Sherlock пишет:
11.06.2011 14:43
Спасибо за оценку. Пускай из меня плохой копирайтер или рерайтер (Вы уже сами решайте), но я мог бы написать о том как писать аудиты или как получить ЛО или какие использовать программы для аудитов. Но эти темы давно избиты и пережеваны по сто раз, а эта тема еще здесь не затрагивалась. В статье я описал основные моменты безопасности и считаю что справился с этой задачей. Статья имеет 96% уникальности и думаю её будет интересно почитать присутствующим здесь. Спасибо.
linyli пишет:
11.06.2011 13:00
Шерлок, можно пару вопросов?
Почему вы считаете, что это относится к безопасности: «одинаковый, в сущности, бюджет для каждого пользователя»?

И еще, если можно, расскажите подробнее о пункте «применение методики двойного контроля за критически опасными участками кода».
Что именно вы понимаете под методикой двойного контроля и какие участки кода вы относите к критически опасным?
Sherlock пишет:
11.06.2011 14:30
Спасибо за вопросы. На первый могу пояснить что имелось ввиду один или единый для всех модулей у пользователя. На второй вопрос отвечу что это общепринятое понятие, в моем понимании оно означает, что должна осуществляться постоянная проверка кода на противодействие всем известным уязвимостям. Используют и проводят её обычно специалисты по безопасности самой компании. Я так понимаю этот вопрос, извините могу и ошибаться. Спасибо.
linyli пишет:
11.06.2011 15:06
Видимо, я неправильно поставила первый вопрос.
Я хотела спросить, что понимается под одинаковым бюджетом модулей и почему это влияет на безопасность? В статье, которую вы взяли за основу, этот момент тоже не пояснен, но это и любопытно...

Двойная проверка обычно обозначает двусторонний контроль, а все-таки не постоянный. Вопрос был, скорее, о применяемой методике двойного контроля, которую вы подразумевали в статье. Речь шла о двойном слепом тесте?

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

И вы не ответили на вопрос про критически опасные участки кода. Думаю, здесь был бы уместен пример...
Sherlock пишет:
11.06.2011 15:24
Ну Вы прямо валите мои поверхностные знания. По поводу кода могу только обратиться к Википедии, которая поясняет: Крити́ческий уча́сток ко́да, или хот-спот (от англ. hot spot — «горячее место» или «горячая точка») — участок кода в программе, исполнение которого занимает длительное время в сравнении с его размерами или, что то же самое, на него приходится существенная доля исполненных инструкций.
По поводу бюджета, там понимается не бюджет модуля, а единый бюджет ПОЛЬЗОВАТЕЛЯ для любого модуля. Как он влияет на безопасность будем разбираться.
linyli пишет:
11.06.2011 15:29
Нет, что вы, не валю :)
Просто пытаюсь понять, как вы сами для себя осмыслили написанное.

Про бюджет вопрос открыт. Я подозреваю, что это кривой перевод зарубежной статьи. Если разберетесь, с тем, что это такое, будет интересно.
Sherlock пишет:
11.06.2011 15:32
Хорошо, постараюсь добить его до конца. Уже есть некоторые наметки в этом вопросе. Спасибо.
Елена Решедько пишет:
11.06.2011 15:38
"единый бюджет ПОЛЬЗОВАТЕЛЯ для любого модуля"... С этого момента, пожалуйста поподробнее. Что за бюджет? Что в себя включает?
Alexey пишет:
11.06.2011 14:08
Интересная статья, это база, на которой строится безопасность. :)
Надежда Дмитриевна пишет:
11.06.2011 16:57
так много слова безопасность, поймала себя на мысли, что ничего кроме этого слова не запомнила.
Надежда Дмитриевна пишет:
11.06.2011 16:58
мне понравилось, никогда почему то не задумывалась о безопасности веб-ресурса...
Lavinia пишет:
11.06.2011 17:01
Шерлок, а почему в статье опущен вопрос SQL-атак на сайт и методов защиты от них? По-моему это точно должно было бы войти в статью..
Sherlock пишет:
11.06.2011 18:05
Это будет тема следующей :-)
Елена Решедько пишет:
11.06.2011 18:26
Лучше не надо))

Пишите о том, что знаете хорошо.
Sherlock пишет:
11.06.2011 18:38
Хорошо не буду.
Lo3a2007, если Вас интересует этот вопрос, Вы можете посмотреть вот на этом сайте, там всё подробно расписано: http://scripts.by/zaschita-php-/-mysql-baz-sayta-ot-atak-sql-in-ektsiyami.html
Alexey пишет:
12.06.2011 13:54
дак если писать обо всех способах атаки, то не хватит одной статьи) есть ещё xss, php include, dos, ddos, чего только нет))
Lavinia пишет:
11.06.2011 19:42
Спасибо за ссылку)
А писать и правда лучше о том, что сам знаешь хорошо, а то пользы от статьи не будет.
Елена Решедько пишет:
11.06.2011 19:44
Истину глаголишь! Некомпетентность чувствуется кожей.))
Sherlock пишет:
11.06.2011 19:47
Может хватит уже. Статья обзорная и основные моменты в ней отражены. Вы что хотите меня убить сразу на первой статье.
Елена Решедько пишет:
11.06.2011 20:06
Да я не Вас конкретно имела в виду, хватит уже все на свой счет принимать.

Если автор не досконально изучил то, о чем собрался писать, по тексту это чувствуется. Фразы построены недостаточно грамотно, термины употребляются неуверенно и т.д. Короче - нюансов куча.
Елена Решедько пишет:
11.06.2011 20:08
Убивать не хочу. Хочу направить Вакшу энергию в верное русло, там где от Вас пользы больше будет.:)

Это у воспитанных людей "хочу помочь" называется, но мы недавно выяснили, что слова "воспитанный человек" - не про меня сказаны.))
Надежда Дмитриевна пишет:
12.06.2011 11:57
статья полезная и затрагивает вещи, которые не рассматривались еще здесь, поэтому хотя бы поэтому он аимеет право жить и быть
Елена Решедько пишет:
12.06.2011 18:30
Он имеет право жить по Женевской конвенции и конституции РФ. ;)

Феликс пишет:
12.06.2011 01:30
Комментарии неплохие. Верно, главное направить энергию в верное русло.
Александр Вайс пишет:
14.06.2011 19:51
Статья ради статьи... точнее, ради рейтинга. Что-то написал, а что не знаю :)
Sherlock пишет:
14.06.2011 20:25
Я вот не пойму, чем тут всем моя статья не понравилась. Статья не обучающая, а обзорная. Смысл статьи был довести до читателей основу. Или тут всех жадность из-за 25 баллов рейтинга задушила. Заберите обратно в таком случае. Труд другого человека легко обхаять, а вот написать об этом ни у кого не хватило. Спасибо, обсуждение закрыто.
Елена Решедько пишет:
14.06.2011 22:32
Вопрос не в рейтинге и уж точно не в медальке.

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

Требования к статье тем выше, чем серьезнее тема затронута. Безопасность - очень серьезная тема, именно поэтому за нее нельзя браться, не накопив достаточно опыта в данной теме.

Резюмирую: писать о безопасности, не занимаясь безопасностью безответственно. Это все равно, что аспирин вместо анальгина советовать только потому, что названия похожие.
Александр Вайс пишет:
14.06.2011 21:40
Собственно дошли руки написать чем не понарвилась.
Статья ОЧЕНЬ неполная (сказано только о 20-30% аспектов безопасности) и не совсем точная из-за рерайта.
1. Доверять безопасность сайта веб-дизайнерам? Кто до такого додумался? Какой веб-дизайнер за такое возьмется? 60% веб-дизайнеров не разбираются даже в верстке, не то чтобы в программировании, серверах, веб-приложениях и уж тем более безопасности.
2. Мониторить защищенность сервера с помощью спец. средств. Каких средств? (это было бы полезно написать!).
3. Не совсем понятно, что автор понимает под аудитом безопасности. Аудит безопасности бывает ОЧЕНЬ разный, т.к. преследует разные цели и проводится по разным стандартам, соответственно и суммы за аудит очень разные. Если говорить о комплексном аудите сферического коня в вакууме, то это примерно 200 000р.
4. Одинаковый, в сущности, бюджет для каждого пользователя. Во-первых, не одинаковый, а "единый бюджет пользователя для всех модулей", согласно первоисточнику. А это уже разные вещи. Взято из Битрикса. Слово "бюджет" еще переводится как "сумка", поэтому я полагаю здесь говорится о том, что все модули находятся как бы внутри одного большого модуля, предназначенного специально для управления всеми модулями, т.е. единый интерфейс контроля над модулями.
5. Методика двойного контроля заключается скорее всего в программном запрете изменения участков кода и подсчете контрольных сумм этих участков.
6. Переустанавливать все ПО, через которое нарушитель проник в систему, в надежде, что он снова не проникнет туда через это же ПО тем же методом - бред :) Есть смысл переустанавливать, если контрольные суммы критических элементов ПО не совпадают с изначальными.
Александр Вайс пишет:
15.06.2011 01:22
Подскажите какую тему по безопасности выбрать. Я тут в ветке форума отписался http://sitepolice.ru/forumpolice/f6/topic1488/?PAGEN_2=4