- Эксплуатационные обязанности
- Необычные и необъяснимые события
- Отклонения от стандартов
- Внеплановая перезагрузка системы
- Идентификация и управление активами
- Системные защитные меры
- Доверенное восстановление
- Контроль входных и выходных данных
- Укрепление систем
- Безопасность удаленного доступа
Операционная безопасность охватывает защитные меры и контрмеры, предназначенные для защиты ресурсов и информации, а также оборудования, на котором размещаются эти ресурсы и информация. Целью операционной безопасности является снижение вероятности возникновения ущерба, вызванного несанкционированным доступом или раскрытием информации. Эта цель достигается за счет ограничения возможностей для злоупотреблений.
В некоторых компаниях организован отдельный Департамент эксплуатации, который отвечает за выполнение действий и процедур, необходимых для обеспечения бесперебойной работы сети и сохранения ее производительности на определенном уровне. В других компаниях для выполнения этих функций могут быть назначены несколько ответственных лиц. В любом случае люди, которые выполняют эти обязанности, несут ответственность за выполнение указанных действий и процедур, они обязаны контролировать и отслеживать определенные вопросы.
Выполнение операций в компьютерной среде может иметь отношение к программному обеспечению, персоналу и оборудованию, однако Департамент эксплуатации зачастую сосредотачивает свое внимание на аспектах программного и аппаратного обеспечения. Нужно понимать, что ответственность за поведение сотрудников и выполнение ими своих обязанностей несет руководство компании, а сотрудники Департамента эксплуатации отвечают за обеспечение недлежащей защиты систем и их предсказуемую работу.
В задачи Департамента эксплуатации обычно входит предотвращение повторного возникновения проблем, снижение количества аппаратных и программных сбоев до приемлемого уровня, а также снижение влияния инцидентов и сбоев. Департамент эксплуатации должен расследовать любые необычные или непонятные случаи, неожиданные повышения загруженности систем, отклонения от стандартов и другие ненормальные ситуации, которые происходят в сети.
Сети, а также аппаратное и программное обеспечение в них, могут быть сложными и динамичными. Происходящие в них события нередко вызывают удивление и могут казаться необъяснимыми. Именно Департамент эксплуатации должен расследовать такие ситуации, диагностировать проблемы и находить их логичное решение.
Рассмотрим пример. Несколько узлов в сети постоянно теряют сетевое соединение без каких-либо видимых причин. Для решения этой проблемы выделяется группа сотрудников Департамента эксплуатации, которая должна контролируемым образом устранить возникшие неполадки, убедившись, что не забыт ни один из возможных источников проблемы. Группа может выполнить проверку соединений между этими узлами и распределительным шкафом, концентраторами и коммутаторами, которые управляют этими соединениями, выполнить проверку возможных дефектов связывающих их сетевых кабелей. Члены группы должны работать методично, пока не найдут причину возникших проблем. Централизованный мониторинг систем и управление событиями могут помочь найти причину проблем и сэкономить массу времени и усилий.
ПРИМЕЧАНИЕ. Управление событиями (event management) обычно реализуется с помощью специализированного продукта, осуществляющего сбор и анализ различных журналов со всех устройств в сети. Такой продукт выявляет шаблоны поведения и потенциально опасные действия, которые человек, скорее всего, пропустит, т.к. объем таких журналов обычно очень велик.
В данном случае «стандарты» относятся к доступному уровню вычислительных возможностей и способам его измерения. Для каждого устройства могут быть установлены определенные стандарты: время нахождения в режиме онлайн, минимальное количество запросов, которые должны обрабатываться в единицу времени, максимальная полоса пропускания, счетчики производительности и т.п. Эти стандарты используется в качестве базового уровня, позволяющего установить факт наличия проблем с устройством. Например, если устройство обычно обрабатывает около 300 запросов в минуту, но вдруг оно начинает тратить на обработку этого количества запросов три минуты, сотрудники Департамента эксплуатации должны изучить это отклонение от стандарта, обычно выполняемого этим устройством. Причиной такого отклонения может быть неисправность устройства или его нахождение под DDoS-атакой. Другой причиной может быть легитимная деятельность, но выполняющаяся способами (или в условиях), которые не были предусмотрены при вводе устройства в эксплуатацию.
Иногда стандарты необходимо пересматривать, чтобы они отражали реальный взгляд на уровень обслуживания, который может обеспечить такое устройство. Если, к примеру, в сервере был заменен процессор с Pentium II на Pentium IV, был в четыре раза увеличен объем памяти и добавлены три дополнительных жестких диска, уровень сервиса для этого сервера следует пересмотреть.
Начальная загрузка системы (IPL – Initial program load) – это термин, использующийся в среде мэйнфреймов, он обозначает загрузку ядра операционной системы в оперативную память компьютера. Загрузка операционной системы на персональном компьютере, является эквивалентом IPL. Это необходимая операция для подготовки компьютера к работе.
Сотрудники Департамента эксплуатации должны исследовать компьютеры, перезагружающиеся без явных причин. Это может указывать на серьезные проблемы операционной системы, или заражение компьютера вредоносной программой.
Управление активами (asset management) – это управление тем, «чем компания владеет». В магазине розничной торговли, это может быть названо управлением запасами, которое будет являться частью ежедневных операций, обеспечивающих точность записей по продажам и данных систем учета, а также позволяющих выявить факты воровства. Те же самые принципы могут применяться к ИТ-среде, но в ней существует гораздо больше аспектов, помимо физического и финансового.
Для уверенности в установке безопасных настроек для аппаратного и программного обеспечения, сначала необходимо знать о том, что они вообще существуют в среде. Управление активами включает в себя получение полного инвентаризационного перечня аппаратного (включая системы и сети) и программного обеспечения, а также дальнейшую поддержку актуальности этого перечня.
Может показаться, что управление активами представляет из себя знание о том, что компания владеет 600 настольными компьютерами от одного производителя, 400 настольными компьютерами от другого производителя и 200 ноутбуками от третьего производителя. Но достаточно ли этой информации для управления конфигурациями и безопасностью этих 1200 компьютеров? Нет.
Немножко углубимся в эту информацию. Достаточно ли будет знать, что эти 600 настольных компьютеров являются моделями 123 от производителя А, 400 компьютеров – моделями 456 от производителя В, 200 ноутбуков – моделями 789 от производителя C? Пока еще нет.
Чтобы иметь полное представление обо всех компонентах среды, которые могут быть субъектом рисков безопасности, необходимо иметь полную информацию о каждом аппаратном устройстве, операционной системе, сетевом устройстве (и его операционной системе), а также каждом приложении, работающим в этой среде. Даже прошивка сетевой карты, установленной в компьютере, может содержать уязвимости, и уж, конечно, драйвера устройств в операционной системе, которые и приводят к тому, что уязвимость сетевой карты может представлять риск нарушения безопасности. Операционные системы представляют из себя относительно хорошо известный и управляемый аспект рисков безопасности. Менее известным аспектом, важность которого постоянно растет, являются приложения (программное обеспечение). К примеру, приложение может содержать неактуальную и уязвимую версию Java Runtime Environment. Или оно может копировать системную библиотеку операционной системы в нестандартное (и неконтролируемое) место, что может привести к наличию уязвимости даже после установки вами патча (ведь патч применится только к оригинальной библиотеке, хранящейся в системной папке операционной системы). Эту уязвимую библиотеку может обнаружить злоумышленник и нарушить безопасность системы, воспользовавшись старым проверенным эксплойом.
Управление активами требует знания всего – оборудования, прошивок, операционных систем, библиотек времени выполнения, приложений и отдельных библиотек – в масштабах всей среды. Очевидно, что только с помощью автоматизированных средств можно выполнить это в полной мере.
Наличие полной инвентаризации всего, что есть во всей среде, является необходимым, но не достаточным. Есть один простой принцип безопасности: если необходимость в компоненте отсутствует, лучше удалить этот компонент. Если компонента нет в среде, он не может создать угрозу для ее безопасности. Однако не всегда это просто сделать. Например, в отдельных случаях такие компоненты могут быть встроены в системы и приложения. В таких случаях, необходимо контролировать их наряду со всеми остальными компонентами, чтобы обеспечить их безопасность.
Стандарты конфигурации – это ожидаемая конфигурация, на соответствие которой проверяется фактическая конфигурация. Любые отклонения от ожидаемой конфигурации должны быть расследованы, поскольку это означает, что либо ожидаемая конфигурация потеряла актуальность, либо, что контроль над средой не является достаточным для предотвращения несанкционированных (или просто незапланированных) изменений в среде. Автоматизированные средства управления активами могут сравнить ожидаемые конфигурации с фактическими настройками компонентов среды.
Возвращаясь к принципу простоты, лучше всего свести количество стандартов конфигураций к разумному минимуму, обеспечивающему потребности бизнеса. Процессы Управления изменениями или Управления конфигурациями, должны охватывать любые изменения в среде, что позволит обеспечить поддержку соответствия стандартам конфигураций. Сведение количества стандартов конфигураций к разумному минимуму, позволит снизить общую стоимость Управления изменениями.
Системные защитные меры (system controls) является еще одной частью операционной безопасности. В операционной системе, должны быть реализованы определенные защитные меры, обеспечивающие выполнение команд в правильном контексте безопасности. В системе есть механизмы, ограничивающие выполнение определенных типов команд, такие команды могут выполняться только тогда, когда операционная система работает в привилегированном или административном режиме. Это защищает безопасность системы в целом и ее функционирование, помогая обеспечить стабильную и предсказуемую работу.
Должны быть разработаны операционные процедуры, которые определяют, из чего состоит правильная работа системы или ресурса. Они должны включать в себя последовательности действий при запуске и выключении системы, процедуры обработки ошибок и восстановления из надежного источника.
Операционная система не позволяет процессам с низким уровнем привилений (как правило, это процессы прикладных программ) получить прямой доступ к оборудованию. Если программе нужно передать команды аппаратному устройству, она направляет соответствующий запрос процессу, имеющему более высокие привилегии. Для выполнения привилегированных аппаратных команд, процесс должен работать в ограниченном и защищенном режиме. Это является неотъемлемой частью архитектуры операционной системы, которая определяет, какие процессы могут выполнять какие команды, основываясь на управляющих таблицах операционной системы.
Многие команды ввода/вывода (I/O) определены, как привилегированные, они могут быть выполнены только процессами ядра операционной системы. Если прикладной программе нужно выполнить какую-либо операцию ввода/вывода, она должна обратиться к привилегированным процессам ядра операционной системы, которые работают на внутренних кольцах защиты. Эти процессы (называемые системными сервисами) либо разрешают процессу прикладной программы выполнить эти действия и временно повышают уровень его привилегий, либо они сами выполняют запрошенные действия от имени прикладной программы (более детально эти вопросы рассматриваются в Домене 03).
При возникновении сбоя или «зависания» операционной системы или приложения, система не должна переходить в небезопасное состояние. Чаще всего, причиной сбоя системы является то, что она столкнулась с чем-то, что было ей воспринято как небезопасное или непонятное, в связи с чем она решила прекратить свою работу и перезагрузить компьютер, а не продолжать выполнение текущих задач.
Реакцией операционной системы какой-либо сбой может быть одно из следующих действий:
- Перезагрузка системы
- Аварийный перезапуск системы
- Холодный запуск системы
Аварийный перезапуск системы происходит неуправляемым (нештатным) образом после системного сбоя. Такой сбой может произойти на уровне ядра или может быть вызван неисправностью системного диска, либо попыткой доступа непривелигированного пользовательского процесса к сегментам памяти ограниченного доступа. Система видит, что это небезопасное действие, но она не может остановить его и вернуться в безопасное состояние без перезапуска. При этом состояние ядра и пользовательских объектов может быть нарушено, а данные могут быть потеряны или повреждены. Поэтому система переходит в режим обслуживания и "откатывает" выполненные действия. Затем она возвращается в целостное и стабильное состояние.
Холодный запуск системы выполняется в случае возникновения неожиданного сбоя на уровне ядра или системного диска, при котором обычная процедура восстановления не может восстановить целостность системы. Система, ее ядро и пользовательские объекты могут быть разрушены и для их восстановления потребуется вмешательство пользователя или администратора.
Важно обеспечить, чтобы система не перешла в небезопасное состояние в случае возникновения таких проблем, она должна правильно выключаться и надлежащим образом восстанавливать безопасное и стабильное состояние (более подробно вопросы, связанные с TCB, компонентами ядра и его работой, рассмотрены в Домене 03).
Ссылки по теме:
- Configuration Management Plans: The Beginning to Your CM Solution, by Nadine M. Bounds and Susan Dart, Software Engineering Institute, Carnegie Mellon University
- Configuration Management Resources from the Georgia Institute of Technology
После системного сбоя
Рано или поздно любая система может выйти из строя, поэтому важно, чтобы обслуживающий ее персонал знал, как устранять в ней неполадки и восстанавливать ее работу. Ниже перечислены шаги, которые должны быть предприняты для этого:
- Войдите в систему в однопользовательском режиме или безопасном режиме (safe mode). Когда происходит холодный запуск системы из-за неспособности системы автоматически восстановить свое безопасное состояние, в этом процессе должен принимать участие администратор. Система может быть загружена автоматически, но только в «однопользовательском режиме» (single user mode), либо должна быть загружена вручную с помощью «Консоли Восстановления». В этих режимах система не должна запускать пользовательские и сетевые службы, файловые системы обычно не монтируются, доступна только локальная консоль. Поэтому администратор должен либо физически находиться рядом с консолью, либо для доступа к ней должны быть внедрены специализированные технологии удаленного доступа, такие как защищенное соединение по модему (dial-in/dial-back), подключенному к последовательному порту этой системы, либо сетевой переключатель KVM (Keyboard Video Mouse – клавиатура/видео/мышь) подключенный к консоли.
- Исправьте возникшую проблему и восстановите файлы. В однопользовательском режиме администратор восстанавливает поврежденную файловую систему (такие повреждения могут произойти, например, в результате внезапного нештатного выключения системы), а затем пытается определить причину сбоя, чтобы предотвратить его повторение. Иногда администратору также требуется произвести откат или, наоборот, отметить откат изменений в базе данных или другом приложении в однопользовательском режиме. В других случаях это происходит автоматически, когда администратор переводит систему из однопользовательского режима в обычный режим, либо выполняется администратором вручную до того, как приложения и службы вернуться в нормальное состояние.
- Проверьте критичные файлы и работу системы. Если проводится расследование причин внезапного выключения и предполагается, что произошло повреждение (например, из-за программного или аппаратного сбоя, выполненного пользователем/администратором изменения настроек или в результате атаки), администратор должен проверить содержимое конфигурационных файлов и убедиться, что системные файлы (программные файлы операционной системы, файлы совместно используемых библиотек, возможно, файлы приложений и т.д.) являются подлинными. Для проверки системных файлов могут использоваться их криптографические контрольные суммы, проверенные с помощью таких программ, как Tripwire. Администратор должен проверить содержимое системных конфигурационных файлов на соответствие документации по системе.
Проблемы безопасности
- Изменение последовательности загрузки (C:, A:, D:) должно быть запрещено. Чтобы обеспечить восстановление системы в безопасном состоянии, система должна быть настроена таким образом, чтобы не позволить злоумышленнику изменить последовательность загрузки системы. Например, на рабочей станции или сервере Windows, только уполномоченные пользователи (администраторы) должны иметь доступ к настройкам BIOS, в т.ч. к настройке перечня устройств, с которых допускается загрузка системы, и последовательности использования этих устройств. Если загрузка системы допускается только с диска C: (основной жесткий диск), и использование для этого никаких других жестких дисков и съемных носителей (например, дискет, компакт-дисков, USB-накопителей) не допускается, настройки системы должны запрещать пользователю (и злоумышленнику) добавлять устройства в перечень загрузки и изменять их последовательность в этом перечне. Если злоумышленник может изменить перечень устройств, с которых возможна загрузка, или их порядок, и может вызвать перезагрузку системы (что всегда возможно при физическом доступе к системе), он может загрузить компьютер со своего собственного носителя информации и провести атаку на программное обеспечение и/или данные системы.
- Запись действий в системные журналы регистрации событий должно быть невозможно обойти. Должна быть обеспечена сохранность системных журналов регистрации событий и файлов состояния системы (system state file) посредством использования разграничения обязанностей и контроля доступа. Иначе пользователи (злоумышленники) смогут скрыть свои действия или измененить состояние, в котором система окажется после следующей перезагрузки. Если какой-либо из конфигурационных файлов может быть изменен неуполномоченным пользователем, и этот пользователь может вызвать перезагрузку системы, он сможет таким образом применить новые (вероятно небезопасные) настройки системы.
- Принудительное завершение работы системы не должно допускаться. Чтобы снизить возможности применения несанкционированно измененных настроек системы, а также возможности вызвать отказ в обслуживании путем направильного завершения работы системы, только администраторы должны иметь возможность завершать работу критичных систем.
- Не должно существовать возможностей перенаправить диагностические данные. Диагностические данные системы могут содержать критичную информацию. Содержимое файлов журналов регистрации диагностических событий (включая вывод этой информации на консоль) должны быть защищены с помощью контроля доступа, запрещающего чтение этих данных кому-либо, кроме уполномоченных администраторов. Неуполномоченные пользователи не должны иметь возможности изменить место для записи диагностических журналов и консольного вывода.
Исходящие из приложения данные имеют прямую связь со входящими данными. Поэтому входные данные должны контролироваться на предмет ошибок и подозрительного содержимого. Если кассир в продовольственном магазине за любую покупку в магазине пробивает чек на 1 рубль, магазин в итоге может потерять значительную сумму денег. Подобные действия могут быть неумышленными, вызванными неумением кассира пользоваться кассовым аппаратом, что потребует проведения обучения кассира, а могут быть целенаправленными, что потребует применения дисциплинарных мер.
Поскольку деятельность большинства современных компаний в большой степени зависит от компьютеров и приложений, обрабатывающих их данные, контроль входных и выходных данных является очень важным. В Домене 08 были рассмотрены различные варианты мошенничества, при которых пользователь вносит изменения в данные, хранящиеся в программе или генерируемые ей на выходе, как правило, с целью получения финансовой прибыли.
Сами приложения также должны быть разработаны таким образом, чтобы принимать только определенные типы входящих данных и выполнять определенные процедуры логического контроя для проверки полученных входных значений. Если приложение запрашивает у пользователя ввод стоимости покупаемого по ипотеке дома, а пользователь вводит 10 рублей, приложение должно повторно запросить у пользователя ввод этой информации, чтобы не тратить время впустую, обрабатывая ошибочные входные данные. Аналогично, если в поле ввода числовых значений пользователь ввел «Иван», приложение должно вывести соответствующее сообщение об ошибке и предоставить пользователю возможность исправить ошибку. Различные контроли входных и выходных данных рассматривались нами более подробно в Домене 09.
Все упомянутые в предыдущих разделах защитные меры, должны быть внедрены и функционировать на непрерывной, безопасной и предсказуемой основе, чтобы обеспечить правильную работу систем, приложений и среды в целом. Давайте рассмотрим несколько вопросов, которые могут вызвать проблемы, если не уделять им достаточно внимания.
- Все онлайн-транзакции должны записываться в журнал с указанием штампа времени.
- Данные, вводимые в систему, должны иметь правильный формат и должны проверяться, на предмет отсутствия в них вредоносных (подозрительных) данных.
- Следует убедиться в том, что выходные данные безопасным образом сохраняются (передаются) в правильное место назначения.
- Перед предоставлением критичных выходных данных, всегда должен требоваться подписанный запрос.
- Баннер в начале и конце должен указывать, кому предназначены данные.
- После создания выходных данных, должно быть реализовано надлежащее управление доступом к ним, независимо от типа их носителя (бумага, диск, лента и т.п.).
- Если отчет не содержит никакой информации (пустой отчет), он должен содержать строку, типа: «нет результатов».
Другим типом ввода в систему могут быть компоненты ActiveX, плагины, обновления конфигурационных файлов или драйверы устройств. Лучше всего, если они имеют криптографическую подпись, поставленную доверенной стороной перед их распространением. Это позволит администратору вручную (или системе автоматически) проверить, что файлы действительно получены от доверенной стороны (производителя, продавца, поставщика) и не были изменены, прежде чем использовать эти файлы на системе, находящейся в промышленной эксплуатации. Например, Microsoft, начиная с операционной системы Windows 2000, ввела проверку цифровой подписи файлов драйверов (Driver Signing), с помощью которой операционная система предупреждает пользователя, если происходит попытка установить драйвер, который не был подписан доверенным субъектом, имеющим сертификат доверенного Удостоверяющего центра. Современные операционные системы Windows (в т.ч. Windows Mobile) по умолчанию настроены на предупреждение пользователя в случае попытки установки неподписанного програмного обеспечения. Обратите внимание, что факт наличия подписи у дистрибутивного файла или драйвера, вовсе не означает, что оно является безопасным и надежным. Наличие подписи дает высокую степень гарантий, что программное обеспечение или драйвер исходят от доверенного производителя, но не более того. Если пользователь не доверяет субъекту (компании или разработчику), который подписал программное обеспечение (драйвер), либо если программное обеспечение (драйвер) не содержат никакой подписи, то это должно остановить пользователя от использования этого программного обеспечения (драйвера) до тех пор, пока их безопасность и надежность не будут подтверждена по другим каналам.
Используемые для обеспечения безопасности защитные меры и средства могут являться физическими, админстративными или техническими. Считается, что если к критичному, с точки зрения безопасности, объекту может быть получен несанкционированный физический доступ, невозможно обеспечить безопасность этого объекта (поэтому критичные данные на портативных носителях информации должны быть зашифрованы). Иными словами, «если я смогу получить доступ к консоли компьютера, я могу стать его владельцем». Очевидно, что дата-центр компании должен быть хорошо защищен физически. Для этого может использоваться охрана, ворота, заборы, колючая проволока, освещение, замки на дверях и т.д. Все вместе это создает сильную физическую безопасность периметра вокруг здания, где хранится ценная информация.
Через дорогу от этого дата-центра находится офисное здание, в котором сотни или тысячи сотрудников сидят изо дня в день, работая с ценной информацией на своих настольных компьютерах, ноутбуках и мобильных устройствах с использованием сетей различных типов. В идеальном мире, приложения и технологии доступа к информации надежно защищали бы данные от любых сетевых атак, однако мир не идеален, и специалисты по безопасности должны обеспечивать защиту ценных данных в реальном мире. Поэтому физические компоненты, из которых состоят сети и через которые передаются потоки ценных данных, также должны быть защищены.
- Коммутационные шкафы (wiring closet) должны быть заперты.
- Сетевые коммутаторы и концентраторы, которые не могут быть по тем или иным причинам размещены в закрытых коммутационных шкафах, должны помещаться в запертые коробки.
- Сетевые розетки в общедоступных местах (например, переговорные комнаты, общедоступные компьютеры и даже телефоны) должны быть сделаны физически недоступными.
Приложение, которое не установлено на компьютере, или отключенная системная служба не могут быть атакованы. Но даже если системная служба отключена, отдельные ее компоненты могут содержать уязвимости, которыми могут воспользоваться профессиональные атакующие, поэтому лучше ненужные компоненты полностью удалять из системы (среды). Компоненты, от установки которых нельзя отказаться в процессе установки системы, и которые нельзя удалить в связи с их глубокой интеграцией в систему, должны быть отключены. Полномочия на их включение должны быть только у уполномоченного системного администратора. Каждое установленное приложение, и, в особенности, каждая работающая служба, должны быть указаны в общей базе данных Управления конфигурациями, чтобы иметь возможность отслеживать уязвимости в этих компонентах.
Компоненты, которые нельзя ни удалить, ни отключить должны быть настроены с использованием самых безопасных настроек, которые, однако, позволят системе эффективно работать для выполнения функций, ради которых эта система была внедрена. "Движки" баз данных, например, должны запускаться от имени непривилегированного пользователя, а не от имени root или SYSTEM. Если система запускает несколько прикладных служб, каждая из них должна работать под собственной учетной записью, т.к. при этом компрометация одной службы в системе не позволит получить доступ к другим службам в этой системе. По аналогии с ненужными службами, из системы должны быть, по возможности, удалены ненужные части отдельных служб, либо отключены, если их удаление невозможно.
Вопросы лицензирования
Компании имеют этическое обязательство использовать только легально приобретенные программные приложения. Разработчики программного обеспечения и группы их отраслевых представителей, такие как Business Software Alliance (BSA), используют агрессивную политику против компаний, которые используют пиратские (нелегальные) копии программного обеспечения.
Компании несут ответственность за обеспечение того, чтобы в их корпоративной среде использовалось только легальное программное обеспечение, и чтобы лицензии реально соблюдались. Обязанности по контролю этого требования возлагаются на Департамент эксплуатации. Автоматизированные системы управления активами (asset management system), или системы управления системами на более высоком уровне, могут сформировать отчет об установленном программном обеспечении во всей среде, в том числе о количестве установок каждого из приложений. Это количество должно на регулярной основе (например, ежеквартально) сравниваться с перечнем приложений, легально приобретенных компанией, и количеством приобретенных лицензий для каждого из них. В случае выявления установленного приложения, для которого не была приобретена лицензия, либо при выявлении количества установок одного приложения, превышающего число приобретенных для него лицензий, должно проводиться расследование. При обнаружении в среде приложения, для которого не был соблюден установленный в компании процесс управления изменениями и процесс закупок, оно должно быть взято под контроль, а сотрудники подразделения компании, которые приобрели/установили приложение с нарушением установленного в компании порядка должны быть обучены и поставлены в известность как в отношении юридических рисков, так и в отношении рисков информационной безопасности, которые могут быть вызваны их действиями. Обычно в таких случаях руководитель соответствующего бизнес-подразделения должен подписать документ, указывающий, что он понимает возникающие риски, принимает их и берет на себя персональную ответственность в случае их возможной реализации.
В случае выявления приложений, в отношении использования которых нет обоснованных потребностей бизнеса, такие приложения следует удалить, а лиц, которые их устанавливали, следует обучить и предупредить, что в будущем подобные действия могут привести к более серьезным последствиям.
Компании должны регламентировать политику использования систем (acceptable use policy), в которой, в частности, указывается, какое программное обеспечение пользователи могут установить самостоятельно, и которая информирует пользователей о регулярно проводимых проверках соблюдения этой политики. Для предотвращения несанкционированной установки пользователями неразрешенного программного обеспечения, должны быть внедрены соответствующие технические защитные меры.
Часто о компаниях, использующих нелицензионное программное обеспечение, сообщают недовольные сотрудники этих компаний (в качестве мести).
Удаленный доступ является важным элементом обеспечения работы компании, он очень помогает, когда компания сталкивается с различными авариями и чрезвычайными ситуациями. Если произошедшая авария или региональная катастрофа не позволяет большому числу сотрудников выполнять работу на своем обычном рабочем месте, но дата-центр (основной или удаленный резервный) продолжает работать, удаленный доступ к компьютерным ресурсам может позволить компании продолжать выполнять многие из повседневных операций почти как обычно. Удаленный доступ может также способствовать снижению операционных расходов за счет сокращения офисных площадей, находящихся в собственности компании или арендованных, снижении потребностей в мебели, кондиционировании, отоплении, уборке, а также на парковке, поскольку многие сотрудники будут работать из дома. Удаленный доступ может быть единственным вариантом для организации работы «мобильной рабочей силы», например, специалистов по продажам, постоянно переезжающим из одного города в другой, которым необходим постоянный доступ к корпоративным ресурсам, чтобы встречаться с существующими и потенциальными клиентами.
Как и все остальное, что позволят бизнесу работать и получать прибыль, удаленный доступ также приносит и риски. Является ли лицо, удаленно регистрирующееся на сервере компании тем, за кого себя выдает? Может быть, кто-то физически или с помощью электронных средств "смотрит через плечо" пользователя, или перехватывает данные, передаваемые по линиям связи? Имеет ли клиентское устройство, с которого он выполняет удаленный доступ, безопасную конфигурацию или его безопасность нарушена установленным на нем шпионским программным обеспечением, троянскими программами и прочим вредоносным кодом?
Удаленный доступ – это «бельмо на глазу» подразделения информационной безопасности и подразделения эксплуатации почти любой компании. Ведь действительно небезопасно разрешать удаленное подключение ко внутренней корпоративной сети компании, ничего не зная об обеспечении безопасности подключающихся устройств – были ли на них установлены актуальные патчи, обновлены ли на них вирусные сигнатуры, не инфицированы ли они вредоносным кодом и т.д. Такие точки доступа нередко используются атакующими для получения доступа во внутреннюю сеть компании. В связи с необходимостью защиты удаленного доступа, производители занялись разработкой технологий контроля безопасности подключающихся удаленно систем и организации карантина для небезопасных систем.
Удаленное администрирование. Чтобы получить преимущества от использования удаленного администрирования, не принимая на себя чрезмерные риски, удаленное администрирование должно выполняться безопасным образом. Ниже приводятся некоторые рекомендации для этого:
- Команды и данные не должны передаваться в открытом виде (т.е. они должны быть зашифрованы). Для этого должен использоваться защищенный протокол, такой как SSH, а не Telnet.
- Действительно критичные системы должны администрироваться локально, а не удаленно.
- Только небольшому числу администраторов должны быть предоставлены права выполнять свою работу удаленно.
- Должна быть внедрена строгая аутентификация для выполнения любых административных действий.
2 комментария:
не перестаю аплодировать вашей работе. у вас нет идеи выложить перевод в doc или pdf?
спасибо! :) да, PDF будет обязательно.
Отправить комментарий