Как избежать глупых утечек информации через корпоративные сайты

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

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

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

Поехали…

 

Как найти потенциальные дыры на вашем сайте? 

Для этого нужно ответить на несколько вопросов.

1)     Есть ли у вас на сайте закрытый раздел для партнеров или клиентов?

Там, где выкладываются конфиденциальные документы (прайсы, партнерские программы, договоры, информация о сделках). Если есть, то это всегда риск. Оставив в стороне вопросы лояльности партнеров, упомяну типичные проблемные места:

  • Доступны ли эти конфиденциальные документы по прямым ссылкам? Частенько бывает так, что документы, выложенные в закрытом разделе на самом деле может скачать любой, у кого есть ссылка, независимо от того, есть у него партнерский доступ или ссылка ему случайно в руки попала. Ссылки запросто могут «уплыть», поэтому конфиденциальные документы должны выкладываться так, чтобы авторизация происходила и при обращении к файлу напрямую по ссылке.
  • Этот раздел действительно закрыт или все сводится к тому, что на него просто нет ссылок в меню сайта? Смех смехом, но так бывает. Конечно, все понимают, что закрытый раздел – это аутентификация и авторизация, но проблема обычно кроется в другом:

     

    • "А вы проверяли?" Иногда оказывается, что большинство разделов закрыты, а про один или два забыли. Очень часто ролевое разделение в системе управления сайта не работает иерархически. То есть закрыв головной раздел, вы вовсе не получите по умолчанию закрытые дочерние разделы. И даже если в процессе создания вы об этом помнили, то где гарантии, что потом в процессе добавления новых разделов и документов веб-мастер не забыл проставить нужные галочки?
    • Кстати, вы не пробовали поискать через поисковую систему сайта эти закрытые разделы и документы? А ну как получится.
  • У вас есть регулярная процедура чистки учетных записей? Т.е. сотрудники, уволившиеся из компаний-партнеров и перешедшие на работу к вашим конкурентам, они все еще имеют доступ к вашим закрытым разделам? Ну ладно, процедура (читай инструмент) у вас конечно есть (у вас же серьезная компания, да), но когда ее запускали в последний раз?

2)     Отправляете ли вы рассылки для партнеров или клиентов? 

В них содержатся ссылки на конфиденциальные документы или информация ограниченного использования в тексте письма? Если да, то тут опять же нюансы появляются.

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

3)     На ваше сайте есть формы, которые заполняют посетители, оставляя свои персональные данные?

Конечно, у вас есть политика обработки персональных данных, с которой пользователи соглашаются, заполняя форму. Но также вероятно, что все анкеты продолжают храниться в БД сайта… вечно. Или вы все-таки регулярно их удаляете?

4)     На чем работают ваши сайты? 

  • Есть ли у вас на сайте форма регистрации (где посетителю нужно вводить пароль)? Если да, то посмотрите, какую CMS-систему вы используете. Если распространенную (неважно – коммерческую или свободную), то скорее всего все ОК, а вот если это кастомная разработка какой-нибудь web-студии или творение ваших программистов, то могут наблюдаться забавные казусы. Кто проверял, что пароли не хранятся или не отправляются куда-нибудь в открытом виде? Бывали, знаете ли случаи… Процентов 10 этих увальней используют один и тот же пароль везде.
  • Какие вообще системы установлены на ваших внешних серверах? Известны случаи, когда веб-сервер с кучей вполне себе правильных и защищенных сайтов, оказывался взломан только потому что из-за чьей-то блажи или цейтнота туда же ставили какой-нибудь вордпресс, про который потом благополучно забывали и не обновляли.

5)     Смешиваете?

Есть несколько принципов, которыми частенько оправдывают глупости – это «производственная необходимость», «соображения экономии» и наш традиционный «да хер с ним». Удостоверьтесь, что основываясь на этих принципах на сервера, где хостятся ваши сайты и порталы не выкладывают что-то, чего там принципиально быть не должно. На этом, кстати и погорели упомянутые товарищи. Чего у них на внешнем сервер делал архив внутренней системы с конфиденциальной информацией? А вот скорее всего когда-то эту глупость оправдали производственной необходимостью. Не делайте так.

6)     Держите все яйца в одной корзине?

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

 

Остается нераскрытым один вопрос – стоит ли так заморачиваться? Но это вы решайте сами. 

  • dav

    Так и представляю, директор прочитал эту статью, вызвал системного администратора и начал ему по пунктам каверзные вопросы задавать 🙂

    А вообще, ждём статью про хранение паролей. 😉

    • Gabreal Safm

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

    • Gabreal Safm

      И никакой записи насчет хранения паролей я не обещал )). Обещал именно эту статью.

      • dav

        Да я и не говорю, что ты её обещал. Просто ждём, недеемся, верим.