Создание системы защиты помещения, выделенного под банковские сейфы

Содержание Нормативные ссылки Введение Глава 1. Теоретическая часть. Анализ систем защиты камер хранения банка

1.1 Анализ методов и систем защиты камер хранения банка

1.2 Основные нормативные, аппаратные и программные требования

1.3 Обоснование построения системы защиты камер хранения банка Глава 2. Практическая часть. Разработка модели системы защиты камер хранения банка

2.1 Структурно функциональная модель системы защиты банковских ячеек

2.1.1 Общая концептуальная модель

2.1.2 Диаграмма уровня А0

2.1.3 «Сопровождение системы

2.2 Анализ информационных потоков в модели системы защиты банковских ячеек

2.2.1 Общая концептуальная модель

2.2.2 Диаграмма уровня А0

2.2.3 «Регистрация персоналии

2.3 Описание основных информационных потоков в модели системы защиты банковских ячеек

2.3.1 Общая концептуальная модель

2.3.2 «Планирование системы доступа»

2.3.3 «Контроль за доступом персонала»

Заключение

Список используемой литературы

Нормативные ссылки

1. ГОСТ Р 51 110−97 Средства защитные банковские. Общие технические требования.

2. ГОСТ Р 52 437−2005 Средства защитные банковские. Депозитные и индивидуальные ячейки. Общие технические условия.

3. ГОСТ Р 5 122 198 Средства защиты банковские. Термины и определения.

4. ГОСТ 12.2.391 Система стандартов безопасности труда. Оборудование производственное. Общие требования безопасности.

5. ГОСТ 50 892 003 Замки и защелки для дверей. Технические условия.

6. Федеральный закон «О банках и банковской деятельности».

7. ГОСТ Р 50 862−96 Сейфы и хранилища ценностей. Требования и методы испытаний на устойчивость к взлому и огнестойкость.

8. ГОСТ Р 51 113−97 Средства защитные банковские. Требования по устойчивости к взлому и методы испытаний.

Введение

На сегодняшний день в мире существует огромное количество технических средств и систем. Перед созданием информационной системы специалисты в области технических средств моделируют проект будущей информационной структуры. Моделирование используют для:

· Оценки необходимых материальных, технических и временных затрат

· Поиска возможных уязвимостей системы и мест утечки информации

· Определения мест проведения тестирования системы

· Определения необходимых кадровых ресурсов

· Проектирования системы потоков данных и отслеживание административно-распорядительной и нормативно-управленческой документации

· и др.

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

Задачей работы является создание системы защиты помещения, выделенное под банковские сейфы.

Банковская ячейка (другими словами — банковский сейф или депозитная ячейка) представляет собой «сейф-бокс» различных размеров: от самой маленькой ячейки, например, для хранения драгоценностей, и до размеров, позволяющих уместить целые произведения искусства.

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

Целями данной работы являются следующие аспекты:

· Спроектировать систему допуска к помещению персонала и клиентов

· Создать систему потока документации с использованием БД банка и специально созданных БД, используемых только данной системой

· Определить документацию, составляющих коммерческую тайну

· Создать систему контроль за содержимым банковских сейфов

· Смоделировать систему отбора и тестирования персонала и элементов системы.

Но помимо всех этих целей, главной остаётся одна: максимально защитить помещение, выделенное под банковские ячейки.

Для реализации поставленных задач и достижения целей используем программу

All Fusion Process Modeler и используем доступные приложения этой программы [1]:

· IDEF0-используем для структурно-функционального моделирования;

· DFD-используем для построения информационных потоков в системе;

· IDEF3-моделируем в режиме реального времени информационные процессы, рассматриваемые в системе.

Глава 1. Теоретическая часть. Анализ систем защиты камер хранения банка.

1.1 Анализ методов и систем защиты камер хранения банка Банковские хранилища компании «Феррум Про» .

Рис 1. Помещение под банковские ячейки.

Хранилища, выпускаемые компанией «Феррум Про» могут быть модульными или монолитными конструкциями (Рис. 1). Модульные конструкции создают возможность сборки хранилищей ценностей любой площади и любых конфигураций.

Монолитная конструкция — это единый железобетонный блок, которые устанавливается в месте эксплуатации.

Модульные конструкции «Феррум Про» обладают рядом преимуществ: их можно собрать в минимальные сроки, можно демонтировать и устанавливать в другом месте, отдельные элементы довольно легкие (меньше 50 кг), их можно устанавливать даже в помещениях, у которых небольшая несущая способность перекрытий.

Разборные сейфы, банковские хранилища, сейфовые комнаты MODUL-X III — XII класс защиты от взлома.

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

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

Рис 2. Система панелей «Модуль Х».

Ценности, хранящиеся в секретной комнате «Модуль Х», страхуются такими компаниями, как «LLOYD OF LONDON» или «CHUBB».

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

Комната создается в соответствии со спецификацией заказчика и вся документация конфиденциально создается в единственном экземпляре и передается исключительно заказчику.

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

Сейфы и комнаты MODUL-X — продукт мировой новизны, отличающийся:

· Высшим уровнем взломостойкости,

· Простотой доставки и монтажа в виде компонентов,

· Эксклюзивностью и конфиденциальностью исполнения,

· Признанием MODUL-X страховыми компаниями Lloyds Of London и Chubb Inshurance.

Преимущества MODUL-X:

· Новая защита из высокопрочной стали и керамики

· Многоточечная система запирания подобно дверям банковских хранилищ

· Конфиденциальность при доставке

· Вес конструкции в собранном виде недоступен для выноса

· Конфигурация и компоновка объема и уровня защиты под требования пользователя

· Быстрый монтаж минимальным ручным инструментом

· Идеальный вариант для арендуемых помещений

· Как правило, единственный вариант для размещения сейфа в помещениях со слабыми перекрытиями, лестничными маршами и лифтами.

· Возможно исполнение любых уровней защиты по ГОСТ Р 508 625−05 или UL TL 30, UL TL 30×6 и стандарта применяемого для ювелирных сейфов

· Размер панели 600×600×80

· Вес панели 50 кг Автоматическая система роботизированных депозитных ячеек SafeStore Auto.

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

Установка SafeStore Auto позволяет предоставлять корпоративным и частным клиентам качественно новый уровень сервиса без увеличения количества сотрудников, оптимизировать работу банковских служащих, повысить рентабельность и сделать банковское учреждение еще более привлекательным для клиентов.

Доступ клиента к своей депозитной ячейке происходит в служебной комнате. После заказа ячейки с использованием банковской карточки и выбранного PIN-кода (в качестве опции, возможна идентификация клиента по его биометрическим параметрам) ячейка автоматически доставляется клиенту через выходной терминал.

Автоматическая система роботизированных депозитных ячеек SafeStore Auto производится в 3-х модификациях: Mini, Midi и Maxi (Рис. 3). Модификации Mini и Midi поставляются как готовые устройства в специальном сейфе, стены которого соответствуют классу безопасности Euro VII EX и могут быть легко установлены в стене подобно ATM терминалу или как отдельно стоящие устройства. SafeStore Auto Maxi конфигурируется в соответствии с требованиями заказчика и монтируется по месту, в имеющемся хранилище или с использованием сертифицированных защитных панелей.

Простое и безопасное хранение ценностей в современных банках. Зона хранилища депозитных ячеек полностью отделена от зоны доступа клиента. С SafeStore Auto нет необходимости в контроле времени открытия и доступа к банковским хранилищам.

Возможен выбор вариантов наполнения хранилища ячейками, предлагающихся в нескольких размерах. Габариты ячеек позволяют хранить папки размером более А4. Ячейки с высотой более 80 мм могут содержать архивные папки с рычажным скоросшивателем.

Рис 3. Варианты роботизированных депозитных ячеек SafeStore Auto.

· 100% безопасность: ячейки самообслуживания всегда находятся в закрытом хранилище и перемещаются только по требованию.

· Четыре уровня контроля доступа: PIN код, электронная карта и ключ клиента, биометрические данные (опция).

· Эффективность: быстрая установка и запуск.

· Мобильность: возможность перемещения в другое место (для моделей Mini и Midi).

· Современный дизайн.

· Защитная сигнализация с сертифицированной по VdS защитой поверхности.

· Управление и контроль через систему мониторинга WINSafeNet.

· Максимальная нагрузка: 30 кг на ячейку.

· Скорость обслуживания: благодаря интеллектуальному контролю системы транспортирования гарантируется очень короткое время доступа (Рис. 4,5,6).

· Экономия пространства: система SafeStore Auto может быть установлена в помещении с ограниченной площадью. Благодаря инновационным решениям, ячейки могут располагаться вдоль одной стороны устройства, а доступ к ним обеспечен с торца хранилища.

· Пользовательский интерфейс: карт-ридер.

· Гибкое расположение выходного терминала.

Рис 4. Визит в круглосуточный автоматический депозитарий.

Рис 5. Традиционный депозитарий.

Рис 6. Автоматический депозитарий.

Информационная система группы компаний AT Consulting.

AT Consulting — группа компаний, основной деятельностью которой является работа в перспективных направлениях управленческого и ИТ-консалтинга, внедрение систем управления ресурсами предприятия, хранилищ данных, систем управления взаимоотношениями с клиентами, автоматизированных банковских систем, разработка заказных решений, аутсорсинговые услуги по сопровождению и поддержке сложных информационных систем.

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

После оптимизации процессов формирования отчетности к проекту подключились непосредственно заинтересованные бизнес-подразделения банка. Работники этих подразделений проводили тщательную сверку отчетов — как алгоритмов их формирования, так и корректность данных. Сверка информации в отчетах SAP BW с балансом банка позволила обнаружить ряд проблем в ИТ-системах и впоследствии их решить. По оценке руководства банка, это стало важным шагом на пути интеграции всех ИТ-систем и последующей еще более основательной поддержке бизнеса со стороны департамента информационных систем (Рис. 7).

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

Рис 7. Схема функционирования BI-подразделения.

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

Сейчас хранилище находится в стадии коммерческой эксплуатации и поддерживается силами сотрудников банка. Также в ходе проекта был сформирован план развития системы отчетности и план оптимизации архитектуры хранилища данных.

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

1.2 Основные нормативные, аппаратные и программные требования камера ячейка хранения банк защита Требования к модульным банковским хранилищам.

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

Модульная бронированная конструкция на металлическом каркасе включает в себя: бронированные панели, стойки, перемычки, дверные блоки, оконные блоки с устройствами передачи (передаточные шлюзы, щелевые лотки, банковские шлюзы, кассовые лотки), защиту от переброса поражающих средств.

По требованиям ГОСТа Р 51 113 и ГОСТа Р 50 862 такие хранилища относятся к VII классу взломостойкости. По желанию заказчика, хранилище может быть с дополнительным полом или без него, дверь и люк могут компоноваться в различных вариантах. Хранилище может быть оснащено УБС-М (унифицированными банковскими стеллажами).

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

Ценности хранятся в металлических шкафах и стеллажах. Конструкции, ограждающие хранилища ценностей, должны соответствовать V-VII классам взломостойкости, в соответствии с требованиями ЦБ РФ. Класс взломостойкости конструкции зависит от армирования, прочности бетона и толщины панелей. Эти конструкции и двери в хранилище рассчитаны на то, что взломать их не возможно даже в течение длительного времени и даже если для этого будут использоваться современные технические средства. Поэтому эти конструкции не делают плотно примыкающими к грунту и соседним помещениям (даже банковским), которые редко используются. В противном случае, будет оставаться возможность разобрать и легко пробить стену хранилища. Поэтому хранилище делается либо окруженным со всех сторон (даже сверху и снизу) помещениями, которые используются постоянно, либо окружается проходом для охраны.

Вход в хранилище оборудуется бронированной дверью V-VII классов взломостойкости, а с внутренней стороны помещения хранилища устанавливается дверь с решетчатым полотном, ячейки которого 15×15 см, а диаметр арматуры — 1,6 см. На бронированной двери устанавливаются замок штурвально-ригельной системы и два замка повышенной секретности, относящиеся к сейфовому типу. Решетчатые двери соответствуют V, VII, IX и XI классам взломостойкости и требованиям ГОСТа Р 50 862−96

Аварийным запасным выходом из хранилищ обычно является бронированный люк V-VII классов устойчивости к взлому. Вентиляция хранилищ осуществляется специальными вводами типа «утка». В хранилища специально устанавливается системы электроснабжения, охранной сигнализации и пожаротушения.

Требования к конструкции и ее составным частям (ГОСТ Р 50 862−96).

· Если сейф снабжен колесами для перемещения, то они должны вводиться в действие или иметь стопорное устройство только изнутри сейфа.

· Сейф может не иметь стопорного устройства, если предусмотрено крепление сейфа к полу или стеле.

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

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

· Сейф может не иметь отверстия для крепления, если он предназначен для встраивания в пол или стену.

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

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

Требования к запирающим механизмам.

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

Таблица 1

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

Таблица 2

Требования устойчивости к взлому.

Сейф или хранилище должны быть устойчивы к взлому и соответствовать одному из классов устойчивости согласно таблице 3.

Таблица 3

Требования к огнестойкости.

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

Таблица 4

Маркировка.

Сейфы хранилища и двери хранилищ, должны быть маркированы с внутренней стороны двери:

— товарным знаком и (или) другими реквизитами предприятия-производителя

— типом (моделью) и порядковым номером продукции

— годом выпуска.

Сертифицированная продукция должна быть маркирована дополнительно:

— классом устойчивости к взлому (продукция, выдержавшая испытания взрывчатыми веществами может быть дополнительно маркирована индексом «ВВ»)

— классом огнестойкости для огнестойких сейфов;

— номером сертификата

— фирменным знаком и другими реквизитами организации, проводившей сертификацию, в т. ч. номер ее Аттестата аккредитации.

На наружной стороне дверей допускается нанесение:

— товарного знака и (или) наименование предприятия-производителя;

— типа (модели продукции);

— знака соответствия, если продукция имеет сертификат по показателям безопасности.

1.3 Обоснование построения системы защиты камер хранения банка Рассмотренный ряд систем функционирования банковских хранилищ не является конечным. Огромное количество фирм предлагает схожие по техническим характеристикам системы, способу ведения документации и методу организации контрольно-пропускной системы. Все фирмы обещают самые высокие показатели надежности, и как следствие 100% защита от несанкционированного доступа посторонних лиц, но на практике банки сталкиваются как раз с противоположным результатом. Арендаторы вынуждены постоянно менять банки или вообще отказать от хранения своих ценностей в них. Конечно, система депозитных ячеек является пока что наиболее надёжной из всех возможных и спрос на такие системы среди клиентов банка растёт, но с другой стороны ещё не обеспечен 100% уровень защищенности. В связи с этим необходимо заново рассмотреть систему защиты банковских ячеек и предложить новые инновационные решения проблем защиты данных помещений. Следует уделить особое внимание:

· Контрольно-пропускной системы

· Системе потоков данных

· Системе организации наблюдения за помещения

· Системе контрольных мероприятий по оценке надежности оборудования, выделенное для сейфовых комнат

· Системе подбора персонала При исследовании каждой системы необходимо определить:

· Возможные места утечки информации

· На каком этапе построения системы необходимо провести тестирование как персонала, так и оборудования

· Уровень конфиденциальности документов и персонал, который может работать с этими документами

· Уровень соответствия созданной системы нормативным документам

· Места согласованности системы с БД

· Меры по адаптации системы в конкретном банке

Глава 2. Практическая часть. Разработка модели системы защиты камер хранения банка

2.1 Структурно — функциональная модель

2.1.1 Общая концептуальная модель Перед построением любой физической модели какой-либо системы необходимо построить ее функциональную модель, которая будет отображать функциональную структуру объекта, т. е. производимые им действия и связи между этими действиями. Для достижения этой цели была использована методология моделирования IDEF0. Целью использования данной методологии моделирования мы определили демонстрацию процесса разработки системы защиты в банках.

При использовании данной методологии можно определить влияние стандартов и нормативных документов; на каких этапах проектирования требуются программно-инструментальные комплексы; осуществление контроля за ходом проектирования.

Как можно видеть из диаграммы A-0, мы поставили перед собой цель разработать систему защиты камер хранения банка (Рис. 8).

Рис 8. Общая концептуальная модель IDEF0.

2.1.2 Диаграмма уровня А0

Построение системы защиты сводится к 4 этапам:

1. Оценка уровня защищенности

2. Создание системы защиты

3. Управление системой защиты

4. Сопровождение системы Мы руководствовались мнениями специалистов при выборе такого пути моделирования. На диаграмме А0 можно увидеть эти этапы. В процессе моделирования приходилось учитывать ограничения по ГОСТам. Также немало важно было решить, использовать или нет мнения специалистов в том или ином вопросе (Рис. 9).

Рис 9. Диаграмма уровня А0.

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

Далее, после соответствующего мониторинга, необходимо перейти к непосредственному созданию системы на основе ГОСТов и проектов.

В этом блоке мы должны не только создать систему защиты банковских ячеек, но и внедрить систему в соответствующий орган, в нашем случае в «Банк»; ознакомить персонал с системой или нанять специалистов, которые будут работать с ней или обучат работе персонал «Банка"(outsoursing-компания).

Следующий блок, на протяжении всей работы системы, занимается её управлением. Он контролирует работу системы и, на основе документов о внедрении, издает приказы, указы и проект для успешной работы и сопровождения системы. Данный блок занимается работой в основном с документацией отражающей техническое состояние системы.

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

2.1.3 «Сопровождение системы»

Подробнее рассмотрим блок «Сопровождение системы», который состоит из следующих компонентов:

Рис 10. Контроль учёта доступа к системе.

1. Контроль учёта доступа к системе (Рис. 10)

· Планирование системы доступа

· Контроль за доступом к системе персонала

· Контроль за доступом к системе клиентов

· Создание отчётной документации доступа В данном блоке мы начинаем внедрять готовую систему в конкретный «Банк». Мы должны составить определенный круг лиц, который имеет доступ к системе и соответствующие полномочия по работе с ней. Учесть всевозможные угрозы и уязвимости в нашей системе. Иметь полные сведения как о персонале, так и о клиентах, для того чтобы мы могли определить имеет ли доступ к системе конкретный человек или нет. После определения каждого из пунктов мы можем создать конкретные отчеты о работе системы с персоналом и клиентами и перейти к следующему блоку.

2. Организационная поддержка системы (Рис. 11)

· Обзор документации о системе

· Техническая поддержка

· Кадровая поддержка

· Анализ состояния системы на данный момент Рис 11. Организационная поддержка системы.

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

3. Тестирование системы к уязвимостям (Рис. 12)

· Определение тестируемого компонента системы

· Идентификация возможных угроз

· Измерение рисков

· Анализ имеющихся средств защиты системы Рис 12. Тестирование системы к уязвимостям.

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

4. Адаптация системы к изменениям во внешней среде (Рис. 13)

· Исследование необходимых изменений системы

· Выбор усовершенствованных технологий

· Внедрение изменений

· Результаты адаптации Рис 13. Адаптация системы к изменениям во внешней среде.

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

2.2 Анализ информационных потоков

2.2.1 Общая концептуальная модель Довольно важно при моделировании определить, как происходит обмен информацией и ее перемещение при построении системы защиты. Для этого нами была выбрана методология DFD.

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

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

Для начала необходимо определить основные потоки данных, которые есть на входе и выходе. Для этого построим контекстную диаграмму (Рис. 14).

Рис 14. Общая концептуальная модель DFD.

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

2.2.2 Диаграмма уровня А0

Для этого построим диаграмму нулевого уровня (Рис. 15).

Данный уровень декомпозиции детально специфицирует внутренние хранилища данных и процессы, а так же потоки данных между ними. Как мы можем наблюдать, у нас имеется 4 базы данных:

* Данные о персонале

* Данные о клиентах

* Сведения о посещаемости

* Данные по контролю Рис 15. Диаграмма уровня А0.

Данные попадающие в систему проходят через 4 процесса:

· Проводится идентификация и аутентификация

· Регистрация персоналии

· Техническая поддержка

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

2.2.3 «Регистрация персоналии»

Подробнее рассмотрим блок «Регистрация персоналии», который состоит из (Рис. 16):

Рис 16. Регистрация персоналии.

1. Сопоставление данных о персоналии (Рис. 17)

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

На первом этапе мы должны учесть немаловажный факт, того что время и дата посещения должны быть унифицированы в определенной последовательности (ДД. ММ. ГГ. ЧЧ. СС) и оно должно быть едино во всей системе, так как иногда даже секунды могут решить многое. Так же может возникнуть сбой в системе времени и даты, и как раз на этом уровне мы проведем проверку .

Далее, исходя из того кто посетил нашу систему, мы запишем время либо в базу данных персонала, либо — клиента. Причем выполняют запись различные блоки.

Рис 17. Сопоставление данных о персоналии.

2. Запись посещения в личное дело персоналии (Рис. 18)

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

Если журнал отсутствует или находится на стадии обработки, то система выдаст нам ошибку и на стадии формирования учётной записи произойдёт сверка с данными службы безопасности. В случае, когда клиент первый раз посещает камеру хранения, просто создастся новый журнал на его имя.

Рис 18. Запись посещения в личное дело персоналии.

3. Данные обработки Службы Безопасности (Рис. 19)

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

Этот уровень необходим не только для проверки персоналии, но и для выдачи видеои аудиоинформации о посещении. Для защиты «Банка» перед клиентами. Предположим: клиент предъявляет претензии по поводу того, что у него из камеры хранения пропали вещи с момента его последнего посещения. Тогда подается информация о клиенте и формируется запрос, в котором оговаривается с какого по какое время необходимо предоставить видеои аудиозаписи. И далее начинается уже расследование. Также необходимо при предоставлении информации проверить степень секретности, которая осуществляется в процессе обработки данных Службой Безопасности.

Рис 19. Данные обработки Службы Безопасности.

4. Формирование учётной записи (Рис. 20)

Рис 20. Формирование учётной записи.

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

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

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

2.3 Описание основных информационных потоков

2.3.1 Общая концептуальная модель С помощью этой методологии мы можем смоделировать в режиме реального времени информационные процессы, рассматриваемые в данной системе. Целью моделирование является продемонстрировать взаимосвязь между планированием системы доступа персонала к камерам хранения в банке и последующем сопровождении системы, а именно контроль за доступом персонала к ячейкам (Рис. 21).

Рис 21. Общая концептуальная модель IDEF3.

В процессе моделирования мы коснемся таких вопросов как:

· Отношения между работами

· Объекты, участвующие в процессе разработки системы доступа к камерам хранения в банке

· Состояния и изменения, к которым подвергаются объекты

· Контрольные точки синхронизации работ

2.3.2 «Планирование системы доступа»

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

Планирование начинаем с выбора специалиста, который обладает необходимыми знаниями в области моделирования. Далее разрабатывается непосредственно сама система, после создания корой необходимо её протестировать в режиме реального времени, чтобы выявить дефекты, сбои в работе или уязвимые места. После нахождения недостатков в работе мы имеем два пути. Первый вариант, реинжиниринг системы либо компонента системы и заново тестируем до тех пор пока не устраним все неполадки в работе системы доступа. Если же первый способ не помог, то мы выбираем альтернативную методологию планирования системы доступа. Здесь же опять мы сталкиваемся с выбором, либо мы заново создаем систему, либо если специалист не имеет навыков в работе с новой методологией, то необходимо найти подходящего специалиста (Рис. 22).

Рис 22. Планирование системы доступа.

После успешного тестирования системы нам необходимо подобрать персонал, обучить и проверить готовность к работе с системой. Если обучение завершилось успешно, то мы можем подписывать договор и далее нам необходимо следить за тем чтобы информация не утекала через персонал. Для этого мы устанавливаем негласное наблюдение, если выявляются утечки информации, планирование возвращается на начальные этапы выбора специалиста, тестирование системы и подбор персонала. Если же все проходит успешно работа на данном этапе завершается (Рис. 22).

2.3.3 «Контроль за доступом персонала»

Когда система разработана и обучен персонал Службы Безопасности, то мы начинаем контролировать персонал банка, который имеет доступ к ячейкам и работает в основном с клиентами. При предъявлении рабочего удостоверения система одновременно проверяет его подлинность и статус удостоверения, т. е. имеет ли данный сотрудник право доступа к камерам хранения. После получения результатов либо происходит отказ в доступе персоналу по какой-либо причине и сообщается об этом в Службу Безопасности, которая должна выяснить причину отказа. Либо персоналу разрешается доступ к помещению, а все его действия записывается в БД «Данные о персонале» (Рис. 23).

Рис 23. Контроль за доступом персонала.

Заключение

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

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

Процедура доступа к банковской ячейке проста и занимает в среднем 10−30 минут — естественно, при наличии свободных ячеек. Но сначала клиенту необходимо определиться с размером ячейки и сроком ее аренды, затем предоставить паспорт ответственному сотруднику банка, который составит договор, а также кассовые документы на оплату аренды сейфовой ячейки и залога за ключ. Клиенту останется подписать документы, внести деньги в кассу банка и получить ключ от ячейки. С этого момента он полновластный пользователь индивидуального банковского сейфа.

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

Почему это надёжно?

· Хранилища индивидуальных банковских сейфов оборудованы современными техническими средствами, обеспечивающими полную неприкосновенность содержимого ячеек.

· Банк несёт ответственность за исправность сейфовых ячеек и за безопасность работы с ними, а также обеспечивает охрану хранилищ.

· «Принцип двух ключей» (ключ банка и ключ клиента) обеспечивает максимальную безопасность содержимого индивидуальной ячейки: никто, кроме клиента или его доверенного лица, не сможет получить доступ к сейфу.

· Помещение в сейфовую ячейку и изъятие из нее предметов вложений, а также работа с ними осуществляется арендатором без контроля со стороны банка.

· Банк берёт на себя всю ответственность за сохранность и неприкосновенность сейфа, а также гарантирует конфиденциальность сведений о клиенте.

Безопасность имущества обеспечивается многоуровневой системой защиты:

· современные средства охранной и противопожарной сигнализации;

· системы видеонаблюдения;

· электронная система контроля доступа;

· пропускная система;

· круглосуточная охрана.

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

В данной работе была рассмотрена традиционная система банковских хранилищ. Процесс моделирования был разбит на 3 этапа:

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

· Защита системы

· Сопровождение системы

· Адаптация системы к изменениям

· Управление системой

2. Данный этап заключается в изучение потока данных по всей системе как со стороны клиентов, так и со стороны персонала. Также была рассмотрена документация, являющаяся коммерческой тайной.

3. Заключающим этапом моделирования является определение мест тестирования на уязвимости.

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

Данный проект пригоден для работы в банке и соответствует нормативным документам.

Список используемой литературы

1. В. С. Симанков «Компьютерное моделирование» г. Краснодар-2004 .

2. Тарасик В. П. «Математическое моделирование технических систем» Учебник. 2004 год. 370 стр.

3. В. Д. Боев, Р. П. Сыпченко «Компьютерное моделирование» Учебник 2010 год. 349 стр.

4. Шелухин О. И., Тенякшев А. М., Осин А. В. — «Моделирование информационных систем»

5. http://peresvet.ru/

6. http://guardmag.com/

7. http://gostrf.com/

8. http://www.kuban-safe.ru/

9. http://www.leater.ua

10. http://www.ferrumpro.ru