Доступ из Web к сети и инфраструктуре
Основная цель службы информационной безопасности — следить за тем, как организация обслуживает свои Web-серверы и системы, которые обеспечивают работу в Web. Постоянно появляются новые критерии безопасности, новые уязвимые места и хакерские средства. Web-узлы повреждаются, похищается информация, и организация рискует из-за этих инцидентов получить негативное паблисити.
Помимо искажения информации существуют проблемы, связанные с воровством информации наподобие тех, которые случаются с содержимым кредитной карточки. Это говорит о том, что существуют слабые места в обслуживании таких записей или в доступе к инфраструктуре, где хранятся эти записи. Тот, чьи узлы были взломаны, знаком с данными проблемами.
Существует столько же способов зашиты данных и сетевой инфраструктуры организации, сколько вариантов реализации Web. В ракурсе разработки правил довольно сложно предложить формулировку, которая удовлетворяла бы конкретной системе. Однако, если не обращать внимания на особенности реализации, то можно найти что-то общее во всех реализациях и изложить это в правилах.
Например, один из способов защиты данных заключается в установке серверов после внутреннего брандмауэра (см. рис. 6.1) и применении специальных методов обеспечения более качественной связи между системами. Несмотря на то, что детали такой схемы должны быть изложены в инструкциях, в качестве руководства для тех, кто внедряет эту систему, нужно разработать правило. Формулировка правила может быть следующей.
Все системы с собственными и клиентскими данными, которые поддерживают Web-сервер, не должны устанавливаться на том же сегменте сети, на котором установлены Web-серверы. Эти вспомогательные серверы должны устанавливаться таким образом, чтобы доступ был возможен только к Web-серверам. Организации следует установить надлежащие средства контроля для обеспечения гарантий того, что вспомогательные серверы могут быть доступны только таким способом, который согласуется с функциями, на которые они запрограммированы.
Другая проблема заключается в выполнении программ, сценариев или иных вспомогательных процедур на Web-сервере. Некоторые организации не испытывают таких проблем и разрешают запускать сценарии, которые работают как часть общего шлюзового интерфейса сервера (CGI — Common Gateway Interface). В других организациях испытывают беспокойство при разрешении запуска всего, что отличается от тестовых страничек сервера. Необходимо быть очень осторожным при утверждении таких правил, поскольку они будут сильно влиять на архитектуру вспомогательных систем Internet вашей организации. Чрезмерная жесткость правил будет неприемлема для организаций, которые пользуются услугами внешних вспомогательных систем.
На Web-серверах должны запускаться только проверенные программы и сценарии, которые функционируют как часть общего со вспомогательными Web-системами шлюзового интерфейса (CGI). Все другие программы должны выполняться на иных системах, не связанных с Web-системами, на которых эти сценарии работают как посредники для такого выполнения.
Сервлеты, аплеты и динамическое содержание
Требования к Web-серверам по выдаче более содержательной информации все увеличиваются: по мере появления новых технологий, создаваемых для распространения этой информации. CGI является всего лишь верхушкой айсберга. В настоящее время, с появлением языка программирования Java, небольшие приложения, называемые аплетами, помогают обеспечить доступ к содержимому на Web-узлах. Но и это не все. Появляются технологии, которые позволяют динамически генерировать содержимое по запросам пользователя. Кроме того, начинают появляться небольшие приложения, размещенные на сервере или сервлеты, а также страницы со встроенными командами, которые выполняются на сервере.
Несмотря на то, что эти технологии расширяют возможности Web-серверов, они создают дополнительные проблемы с безопасностью. Во-первых, новые технологии работают в той же системе, что и Web-сервер. Сбои или другие помехи могут вызвать много различных проблем с защитой сервера.Во-вторых, эти размещенные на сервере программы не имеют отдельного интерфейса, безопасность которого можно было бы оговорить в правилах, ограничивающих доступ к вспомогательным системам.
Организация должна оценить целесообразность применения таких новшеств в соответствии с создаваемыми ими потенциальными проблемами, а также разработать правила их применения. Конечно, вы можете решить, что модель производственной деятельности вашей организации не может обойтись без их применения. В таком случае необходимо обеспечить разработку таких правил безопасности, которые обеспечивали бы соблюдение норм безопасности теми, кто внедряет вспомогательные системы, обеспечивающие безопасный интерфейс для конфиденциальных данных.
