IT-безопасность: стоит ли рисковать корпорацией? - [27]

Шрифт
Интервал

Подключение к внешнему миру похоже на снежный буран. Он может начаться с отдельных порывов ветра, а затем быстро превращается в плотную снежную завесу, через которую вы не можете увидеть своих ног. Если вы не сможете контролировать внешние подключения, то вы споткнетесь или упадете лицом в снег — запросто. Теперь посмотрим…

Соединение с партнерами

Компания JFC Farmaceutical захотела предоставить доступ к своей информации одному из своих клиентов для ускорения совместного исследовательского проекта. Клиенту, компании McConnell Drugs, был нужен доступ к информации, хранящейся на сервере базы данных (Drug10). Технической стороной подключения клиента занимался системный администратор Дэйв Ферлонг.

Так как Дэйв раньше никогда не работал над проектом такого масштаба, то он начал смотреть документацию. Он обнаружил, что у JFC нет утвержденной архитектуры или политики по подключению клиентов к ее интранет. Поэтому Дэйв попросил совета у эксперта компании по брандмауэрам Фреда Джонсона. Вместе Фред и Дэйв выработали свой план. Они подключили сервер базы данных к Интернету для того, чтобы сотрудники McConnell Drugs имели доступ к информации. К сожалению, они подключили сервер базы данных напрямую к Интернету, не поставив впереди него брандмауэр для его защиты и не проведя настроек безопасности на сервере базы данных. Такая конфигурация оставила дверь к сети JFC широко открытой. Было только вопросом времени, чтобы в нее «зашел» хакер. Это как раз и случилось — хакер зашел прямо в дверь.

Как смогли администратор по брандмауэрам и системный администратор сделать такую серьезную ошибку? Кто дал им полномочия на принятие такого решения?

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

День 1-й: Архитектура безопасности

Фред и Дэйв вместе стали решать, как обеспечить работоспособный доступ. Так как у Фреда не было письменного документа о том, как подключать клиентов к сети JFC, то они вдвоем обсудили, как предоставить клиенту доступ к информации на Drug10 (сервере базы данных) и как это реализовать. В общем, Фред и Дэйв решили подключить Drug10 прямо к Интернету, чтобы McConnell Drugs смогла иметь доступ к серверу через Интернет. Они предположили, что настроят Drug10 для двух целей. Во-первых, Drug10 должен служить брандмауэром. Во-вторых, что более важно для Дэйва, компании McConnell Drugs должен обеспечиваться доступ к нужной информации.

Фред имел опыт в установке брандмауэров и подключении систем к Интернету и поэтому согласился помочь Дэйву.

Несколько недель спустя; Политика установки средств безопасности

Дэйв закончил свою часть работы первым. Время отклика Drug10 уже его не удовлетворяло. Поэтому перед подключением сервера к Интернету Дэйв установил в него более мощную систему и загрузил программное обеспечение. Так как у Дэйва не было каких-либо политик или процедур подключения систем к Интернету, то он просто проделал стандартную установку. У Дэйва не было идей по настройке безопасности систем, и он посчитал, что с этим справится Фред как специалист по брандмауэрам. Но у Фреда тоже не было идей.

На следующий день: Кто отвечает за безопасность

Фред подключил сервер базы данных к Интернету. Затем он предоставил доступ McConnell Drugs, чтобы они могли копировать файлы из Drug10 на систему в их сети. Фред вообще не думал о настройке безопасности системы, так как считал, что это работа Дэйва. Он полагал, раз все получили доступ к тому, что им надо, то его работа на этом закончена. Фред приступил к другой работе.

Еще через 29 дней: Хакер захватывает контроль

Было лишь вопросом времени, чтобы хакер обнаружил незащищенную сеть. Хакер взломал Drug 10 и захватил контроль над сервером базы данных. Он заменил важные системные файлы и оставил «черный ход» в системе для легкого доступа при следующем визите.

С этого момента сеть компании McConnell Drugs стала тоже подвергаться риску. Сотрудники компании брали информацию из системы, которая могла быть заражена вирусом, «червем», «троянским конем» или чем-то подобным. Даже если предположить, что хакер не был злоумышленником (довольно рискованное предположение), все равно результаты взлома могли быть опустошительными. Представьте себе, что вы обнаруживаете утром в понедельник всю информацию по персоналу компании опубликованной в Интернете, Представьте себе также возмущение своих сотрудников, которые думали, что сведения о них, их заработной плате и служебные характеристики являлись конфиденциальными. Теперь вспомните, в какой стране мы живем. Как всем известно, возмущенные американцы так просто не успокаиваются — они бегут к адвокату!

Кстати, о юристах. Хакер, прогулявшийся по интранет JFC, мог уничтожить всю их информацию и заразить или уничтожить информацию McConnell Drugs тоже. Теперь подумайте об ответственности. Конечная ответственность за уничтоженную информацию, очевидно, лежит на хакере. Но корпоративные судебные разбирательства очень часто основываются на поиске того, кто может заплатить, а не того, кто должен платить. Несомненно, JFC с ее финансовым положением представляла бы собой лучшую, более крупную мишень для юристов, чем бедный хакер, даже если хакер сразу был бы пойман.