Дипломная работа тема работы Обеспечение безопасности системы управления инфраструктурой центра обработки дан


Глава 4 Реализация системы управления инфраструктурой



Pdf просмотр
страница3/5
Дата14.11.2016
Размер2.99 Mb.
Просмотров1934
Скачиваний3
ТипДиплом
1   2   3   4   5
Глава 4 Реализация системы управления инфраструктурой
Система управления инфраструктурой ЦОД была реализована в соответствии с требованиями из Глава 2 и концептуальной моделью, сформулированной в пункте 3.6. На рисунке 2 изображен пример поведения администраторов и злоумышленника в условиях системы управления после модернизации.
У1
У2
У3
ПК1
ПК2
user: user1; key: x user: user1; key: x user: user2; key: y
ПК3
user: root; pass: a, b
УЖ
УУ
д о
б ав ит ь u
ser
2
; ke y2
Журнал:
user1 вошел с ПК1
с УУ получен user2 с key2
Журнал:
user1 вошел с ПК1
с УУ получен user2 с key2
root отказано ПК3
root отказано ПК3
ПК3 заблокирован
Журнал:
с УУ получен user2 с key2
user2 вошел с ПК2
Журнал:
У1: user1 вошел с ПК1
У2: user1 вошел с ПК1
УУ: user1 добавил user2 c key2
У1: с УУ получен user2 с key2
У2: с УУ получен user2 с key2
У3: с УУ получен user2 с key2
У3: user2 вошел с ПК2
У2: root отказано ПК3
У2: root отказано ПК3
У2: ПК3 заблокирован
Рисунок 2 — Система управления после модернизации

56
Как видно из рисунка 2, администраторы аутентифицируются с ПК1 и
ПК2 используя четко идентифицирующие их личные учетные записи и личные ключи. Администратор с именем пользователя user1 использует УУ для добавления учетной записи user2 на У1, У2 и У3. Для этого он изменяет конфигурацию этих узлов на УУ, а узлы получают обновление конфигурации при следующем обращении к УУ. Злоумышленник с ПК3 пытается осуществить атаку подбора учетных записей на У2. После нескольких неудачных попыток аутентификации он оказывается заблокированным. Все журналируемые события сохраняются в локальных журналах узлов и дублируются на УЖ.
4.1 Узел управления
Для размещения УУ была создана виртуальная машина суммарная информация о которой отображена на рисунке 3.
Рисунок 3 — Суммарная информация о виртуальной машине УУ
Следует отметить, что на рисунке 3 значение параметра «Guest OS»

57 неверно отображает версию гостевой операционной системы. Данный параметр выставляется вручную из списка поддерживаемых операционных систем конкретной версией гипервизора VMware ESXi. Debian GNU/Linux 7 является максимальной версией Debian, которую поддерживает гипервизор VMware ESXi
5.5. Несмотря на то, что гипервизор 10.101.10.3, на котором обеспечивается работа данной виртуальной машины имеет версию VMware ESXi 6.0U2, которая поддерживает Debian GNU/Linux 8, версия виртуальной машины оставлена совместимой с VMware ESXi 5.5, так как инфраструктура ЦОД еще содержит гипервизоры данной версии. Сделано это с целью обеспечения возможности отката версий гипервизоров в случае серьезных проблем в работе VMware ESXi
6.0 и выше.
После создания виртуальной машины туда была установлена операционная система Debian GNU/Linux 8 «Jessie». Были произведены базовые настройки сети в конфигурационных файлах /etc/network/interfaces и
/etc/resolv.conf. Первый содержит такие параметры IPv4, как IP-адрес, маска подсети и шлюз по умолчанию. Во втором файле перечисляются IP-адреса серверов доменных имен и параметры поиска имени в доменах. Несмотря на то что в подсети, где был расположен УУ, имеется DHCP-сервер, производящий автоматическое конфигурирование сетевых параметров узлов, было принято решение установить статические параметры IPv4 на УУ. Для того чтобы работоспособность УУ не зависела от работоспособности сервера DHCP.
Была настроена почтовая служба Exim для пересылки локальной почты через почтовый релей ТПУ — relay.tpu.ru. В конфигурационном файле /etc/aliases учетной записи администратора root был присвоен псевдоним в виде адреса электронной почты группы администраторов GNU/Linux структурного подразделения ГИУ. Это позволило группе администраторов получать электронную почту о важных событиях в операционной системе, так как обновление программного обеспечения или реакция программного продукта
Fail2ban на атаку подбора учетных записей.
Был установлен пакет программного обеспечения open-vm-tools. Этот

58 программный содержит открытую версию программного продукта VMware
Tools. Назначение данного программного продукта в обеспечении лучшей совместимости гостевой операционной системы с гипервизором VMware ESXi.
Достигается это благодаря интерфейсу между гостевой операционной системой и гипервизором, который предоставляет служба Open VMware Tools. К примеру, это позволяет отдавать виртуальным машинам больше оперативной памяти, чем есть у гипервизора. Open VMware Tools увеличивают стандартное значение таймаута блочных устройств с 30 до 180 секунд для обеспечения корректной обработки аварийной ситуации в дисковой подсистеме гипервизора, когда активный путь к системе хранения данных выходит из строя и гипервизор осуществляет переключение на резервный.
Был настроен межсетевой экран Netfilter. Для этого был создан файл
/etc/iptables.rules, в котором были описаны правила экранирования в формате пригодном для загрузки утилитой командной строки iptables-restore. Правила
Netfilter были настроены в стиле «запрещено всё что не разрешено». Правила, на которые стоит обратить внимание приведены ниже:
1. -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
2. -A INPUT -s 10.11.12.13/32 -p tcp -m conntrack --ctstate NEW \
-m tcp --dport 22 -j ACCEPT
3. -A INPUT -s 109.123.155.0/24 -p tcp -m conntrack --ctstate NEW \
-m tcp --dport 8140 -j ACCEPT
Правило под номером один разрешает прохождение всех пакетов по входящим соединениям, находящимся в состояниях установлено
(ESTABLISHED) и порождено
(RELATED).
Соединение считается установленным, если оно прошло все три стадии тройного рукопожатия протокола TCP, подробнее в пункте 3.3.1 настоящей работы. Соединение считается порожденным, если оно связано с другим соединением, имеющим статус установлено.
Правило под номером два разрешает прохождение входящего TCP пакета с адреса 10.11.12.13/32 на порт 22 для соединений в состоянии новое (NEW).
Состояние новое означает, что для данного правила подходят только пакеты с

59 поднятым флагом SYN и опущенным флагом ACK, т.е. пакеты инициирующие тройное рукопожатие протокола TCP.
Правило под номером три работает точно так же, как и предыдущее, но только для TCP порта 8140 и отправителей из диапазона адресов 109.123.155.0/24
— в котором расположены управляемые узлы. Именно на этот порт обращаются агенты puppet расположенные на них.
Для того чтобы правила межсетевого экранирования сохранялись после перезагрузки операционной системы был создан исполняемый файл
/etc/network/if-pre-up.d/iptables, следующего содержания:
#!/bin/bash
/sbin/iptables-restore < /etc/iptables.rules
Первая строка файла /etc/network/if-pre-up.d/iptables говорит о том, что этот файл должен быть интерпретирован интерпретатором /bin/bash. Вторая строка содержит путь до утилиты iptables-restore, которой на вход передается содержимое файла /etc/iptables.rules. Исполняемые файлы, содержащиеся в каталоге /etc/network/if-pre-up.d/, исполняются каждый раз, до того как какой- либо сетевой интерфейс операционной системы переходит из выключенного состояния во включенное. Утилита iptables-restore считывает содержимое файла
/etc/iptables.rules и загружает находящиеся в нем правила в ядро операционной системы.
Были установлены пакеты puppet, puppetmaster, puppetdb, puppetdb- terminus. Первый отвечает за установку агента puppet при помощи которого осуществляется настройка локального узла. Второй пакет обозначает серверную часть puppet — именно к ней будут подключаться агенты с удаленных узлов.
Третий содержит схему базы данных, в которую будет складироваться вся необходимая серверу информация. Четвертый пакет отвечает за подключение сервера к базе данных, с этой целью были отредактированы конфигурационные файлы /etc/puppet/puppetdb.conf и /etc/puppet/puppet.conf. В первом были установлены параметры подключения к базе данных, а во втором указано серверу использовать базу данных для сохранения информации о управляемых узлах и

60 тип базы данных.
В файле /etc/puppet/manifests/site.pp был определен один управляемый узел — это непосредственно сам сервер управления. Его определение выглядит следующим образом: node 'puppet.tpu.ru' { service { puppet: ensure => running, enable => true, } service { puppetdb: ensure => running, enable => true, } service { puppetmaster: ensure => running, enable => true, }
}
Здесь мы указали puppet агенту, что сервисы puppet, puppetdb и puppetmaster должны быть запущены и включены в автозагрузку. Если настоящее состояние сервисов отлично от указанного, то агент должен выполнить все необходимые действия, для приведения сервисов к требуемому состоянию.
Примеры определений управляемых узлов в файле /etc/puppet/manifests/site.pp приведены в приложении А.
4.1.1 Модуль tpu_sshd
Для управления настройками удаленного доступа был разработан модуль к puppet — tpu_sshd, в котором описан класс tpu_sshd и два его наследника tpu_sshd::sec_lvl1 и tpu_sshd::sec_lvl2. Исходный код модуля tpu_sshd приведен в приложении Б. Класс tpu_sshd описывает требуемое состояние службы OpenSSH на управляемых узлах:
 package { 'openssh-server': ensure => latest } — пакет с OpenSSH должен быть установлен и иметь последнюю доступную версию;
 service { 'ssh': ensure => 'running' } — сервис должен быть запущен;
 service { 'ssh': enable => 'true' } — сервис должен быть включен в автозагрузку;

61
 service { 'ssh': subscribe => File[sshdconfig] } — сервис подписан на файл sshdconfig, если в дальнейшей конфигура- ции будет определен файл sshdconfig и его конфигурация будет от- личаться от текущей, то сервис ssh, будет считаться измененным и агент перезапустит его.
В классе tpu_sshd, помимо состояния OpenSSH, описано требуемое состояние программного пакета Fail2ban. Требуемое состояние Fail2ban почти во всем повторяет состояние OpenSSH. Разница заключается в том, что для Fail2ban прописаны конфигурационные файлы
/etc/fail2ban/jail.local и
/etc/fail2ban/jail.conf. file { '/etc/fail2ban/jail.local' : ensure => present, owner => root, group => root, mode => '0600', source =>
"puppet:///modules/tpu_sshd/jail.local.${::osfamily}.${::os_maj_version}"
, require => Package['fail2ban'], notify => Service['fail2ban'],
}
Получая такую конфигурацию агент puppet должен убедиться в наличии конфигурационного файла /etc/fail2ban/jail.local и привести его к виду доступному по адресу puppet:///modules/tpu_sshd/jail.local.${::osfamily}.${::os_maj_version}, где .${::osfamily} и ${::os_maj_version} раскрываются в имя дистрибутива и номер версии дистрибутива соответсвенно. К примеру, для Debian 7 полный путь к файлу получится puppet:///modules/tpu_sshd/jail.local.Debian.7. Адрес этого файла на узле управления /etc/puppet/modules/tpu_sshd/files/jail.local.Debian.7.
Параметры owner, group и mode определяют хозяина, группу и режим доступа к конфигурационному файлу соответственно. Конфигурационный файл требует описания пакета fail2ban и оповещает сервис fail2ban в случае изменений конфигурации.

62
К сожалению разные дистрибутивы GNU/Linux используют разные версии Fail2ban с сильно разнящейся конфигурацией. По этой причине для каждого дистрибутива и каждой версии дистрибутива были написаны свои конфигурационные файлы.
Два класса tpu_sshd::sec_lvl1 и tpu_sshd::sec_lvl2 являются наследниками класса tpu_sshd и расширяют его функционал в части описания конфигурационного файла sshdconfig. class tpu_sshd::sec_lvl1 inherits tpu_sshd { case $::osfamily {
'Gentoo': { file { 'sshdconfig': name => '/etc/ssh/sshd_config', source => 'puppet:///modules/tpu_sshd/sshd_config_lvl1', require => Package['ssh'],
}
}
'Debian', 'RedHat': { file { 'sshdconfig': name => '/etc/ssh/sshd_config', source => 'puppet:///modules/tpu_sshd/sshd_config_lvl1', require => Package['openssh-server'],
}
}
}
}
В классах tpu_sshd::sec_lvl1 и tpu_sshd::sec_lvl2 был использован оператор case при помощи которого осуществляется персонализация конфигурации для разных дистрибутивов.
На сервере puppet было определено два конфигурационных файла
OpenSSH
"/etc/puppet/modules/tpu_sshd/files/sshd_config_lvl1" и "/etc/puppet/modules/tpu_sshd/files/sshd_config_lvl2". Оба файла запрещают аутентификацию под учетной записью root — опция PermitRootLogin в значении no. Отличительной особенностью первого является запрет аутентификации по паролю — опция PasswordAuthentication в значении no и опция
KbdInteractiveAuthentication в значении no.

63
4.1.2 Модуль tpu_ssh_acc
Для распространения учетных записей администраторов между управляемыми узлами был написан модуль tpu_ssh_acc. Экземпляры данного модуля подробно приведены в приложении В. В модуле определен родительский класс tpu_ssh_acc, который накладывает требование require ::tpu_sshd — это означает, что этот класс и все дочерние классы будут применены только при условии, что к узлу применен класс tpu_sshd.
В модуле определены дочерние к tpu_ssh_acc классы: mind, ora, net, ns, backup. Эти классы содержат администраторов соответствующих направлений в структуре организации управления по информатизации ТПУ.
 mind (Main Informational Department) — ГИУ;
 ora (Oracle) — группа администраторов продуктов Oracle;
 net (Network) — группа администраторов сети;
 ns (Name Server) — группа администраторов серверов доменных имен;
 backup — группа администраторов резервного копирования.
Администраторы определяются конструкцией user { 'user1': ensure => present, forcelocal => true, managehome => true
}
Которая определяет имя администратора, в данном случае user1, состояние — он должен существовать на управляемом узле. Независимо от того, какие механизмы аутентификации настроены — администратор должен присутствовать на узле локально. Для администратора должен быть создан домашний каталог.
Помимо базовых параметров, администратору может быть добавлен открытый ключ, для аутентификации на узлах и параметры на каких условиях он

64 может повышать свои привилегия до уровня root.
Открытый ключ описывается в блоке ssh_authorized_key. Связь блока описывающего администратора и блока с открытым ключом осуществляется через строку require => User[' user1'].
4.1.3 Модуль tpu_autoupdate
Для управление процедурой автоматического обновления управляемых узлов был написан модуль tpu_autoupdate. Исходный текст данного модуля приведен в приложении Г. Процедура автоматического обновления для дистрибутивов операционной системы GNU/Linux зависит от пакетного менеджера этого дистрибутива.
Узлы под управлением дистрибутива Debian используют в качестве пакетного менеджера программный продукт APT. Автоматической обновление дистрибутива Debian было реализовано при помощи пакета unattended-upgrades.
Было определено два конфигурационных файла /etc/apt/apt.conf.d/50unattended- upgrades и /etc/apt/apt.conf.d/20auto-upgrades.
В файле /etc/apt/apt.conf.d/50unattended-upgrades определили, что следует устанавливать только обновления безопасности, отчеты о изменениях направлять локальному пользователю root, не допускать автоматической перезагрузки узла.
В файле /etc/apt/apt.conf.d/20auto-upgrades производится включение или отключение автоматического обновления изменением значения параметра
APT::Periodic::Unattended-Upgrade. Значение 1 — автоматическое обновление включено, 0 — выключено.
Узлы под управлением дистрибутивов, основанных на пакетной базе Red
Hat Enterprise Linux, используют в качестве пакетного менеджера программный продукт YUM. Автоматическое обновление подобных дистрибутивов было реализовано при помощи программного пакета yum-cron. Синтаксис и расположение конфигурационного файла программного пакета yum-cron

65 отличается в разных версиях дистрибутивов. Для решения это проблемы наряду с макросом ::osfamily был задействован макрос ::os_maj_version, чтобы персонифицировать конфигурацию к конкретной версии конкретного дистрибутива.
4.1.4 Модуль tpu_mirror_repository
В процессе опытной эксплуатации модуля tpu_autoupdate было принято решение разработать модуль tpu_mirror_repository. Назначение этого модуля определять на управляемых узлах в качестве источников пакетов для пакетных менеджеров APT и YUM сервер, расположенный в пределах адресного пространства ЦОД. Во-первых, этот шаг уменьшил нагрузку на дорогостоящие внешние каналы передачи данных. Во-вторых, упростил настройку узлов, которым запрещен доступ во внешнюю сеть. Исходный текст разработанного модуля приведен в приложении Д.
4.1.5 Описание конфигурации атомарного управляемого узла
После того как были разработаны вышеперечисленные модули была проведена из опытная эксплуатация на ряде узлов ЦОД. Для этого в файле
/etc/puppet/manifests/site.pp были созданы записи этих узлов следующего вида node 'filecloud.tpu.ru' { include tpu_sshd::sec_lvl1 include tpu_ssh_acc::mind include tpu_mirror_repository include tpu_autoupdate
}
Вышеприведенная конструкция описывает конфигурацию узла filecloud.tpu.ru. Предписывает использовать профиль удаленного доступа первого уровня, т.е. разрешена аутентификация только по открытым ключам.

66
Предоставляет доступ администраторам из группы mind, т.е. сотрудникам ГИУ.
Настраивает в качестве источников пакетов программного обеспечения ресурс в пределах адресного пространства ЦОД mirror.tpu.ru. Определяет параметры автоматического обновления.
4.2 Узел журналирования
Для размещения УЖ была создана виртуальная машина суммарная информация о которой размещена на рисунке 4.
Рисунок 4 — Суммарная информация о виртуальной машине УЖ
Были произведены базовые настройки операционной системы. Правила межсетевого экрана Netfilter для данного узла отличаются от УУ в части перечисления разрешенных входящих портов. В данном случае для входящих

67 подключений был разрешен порт 514 по протоколам UDP и TCP. Порт 514 прослушивается службой rsyslogd, которая отвечает за прием, фильтрацию и передачу журналируемых сообщений на хранение.
Параметры Rsyslog были определены в конфигурационном файле
/etc/rsyslog.d/00-remote.conf. Для того чтобы Rsyslog прослушивал порт 514 по протоколам UDP и TCP были задействованы модули imudp и imtcp.
В качестве хранилища журналируемой информации была использована
СУБД MySQL. Средствами пакетного менеджера APT к Rsyslog был установлен модуль rsyslog-mysql, который произвел инициализацию схемы базы данных
Syslog.
В конфигурационном файле /etc/rsyslog.d/00-remote.conf был определен фильтр, передающий все сообщения, источником которых не является сам узел журналирования, в базу данных Syslog. Следом за фильтром идет конструкция
“&
”, которая говорит службе Rsyslog прекратить обработку сообщения, если они были обработаны предыдущим правилом.
1. if $fromhost-ip != '127.0.0.1' then :ommysql:localhost,Syslog,rsyslog,pass
2. &

Для оперативного доступа к журналируемой информации и возможности производить поиск и фильтрацию п ней было принято решение установить на
УЖ программный продукт LogAnalayzer 3.6.6, который на май 2016 всё еще остается последним стабильны выпуском [57]. Дистрибутив данного программного продукта был получен с официального сайта проекта и развернут в каталог /var/www/ узла журналирования, а в /etc/apache2/sites-available/ добавлен конфигурационный файл с описанием параметров доступа к данному веб-интерфейсу. Параметры подключения веб-интерфейса к базе данных Syslog сохранены в файле /var/www/loganalyzer/config.php.
Для предотвращения чрезмерного увеличения объема базы данных Syslog было принято решение регулярно архивировать часть информации и удалять из базы данных строки, переданные в архив. С этой целью был написан небольшой

68 сценарий.
1. /usr/bin/mysqldump Syslog | gzip -c > /root/backup/ \ rsyslog-`/bin/date +%F`.sql.gz 2>>/var/log/rsync-backup.log
2. cd /var/www/loganalyzer/cron
3. /usr/bin/php ./maintenance.php cleandata 1 olderthan 1296000 \
&>>/var/log/rsync-backup.log
В первой строке используется утилита mysqldump, которая преобразует содержимое базы данных Syslog в текстовый описанный на языке SQL. Результат работы утилиты mysqldump передается на вход утилите gzip, которая сжимает получаемую информацию без потерь алгоритмом LZ77. Выход утилиты gzip перенаправляется в файл вида /root/backup/rsyslog-2016-05-15.sql.gz. После завершения архивирования базы данных системном интерпретатору php передается для исполнения файл maintenance.php из поставки программного продукта LogAnalayzer с параметрами указывающими удалить строки с датой регистрации старше 1296000 секунд, что равняется 15 дням.
В системный планировщик узла журналирования была добавлена строка запуска сценария архивирования и удаления строк таблицы Syslog.
1 0 1,15 * * root /usr/local/bin/rsyslog_backup.sh
В соответствии с этой настройкой каждую первую секунду нулевого часа каждого 1 и 15 числа каждого месяца от пользователя root будет запущен сценарий, который расположен по адресу /usr/local/bin/rsyslog_backup.sh.


69
Глава 5 Финансовый
менеджмент,
ресурсоэффективность
и
ресурсосбережение
В данной работе была поставлена цель создать систему управления инфраструктурой центра обработки данных при помощи существующих свободных программных решений.
Система должна была интегрироваться в уже существующую инфраструктуру без покупки дополнительных программных или аппаратных средств.
Следовательно, необходимо было провести исследование существующей инфраструктуры, ознакомиться с перечнем доступных свободных решений, выбрать наиболее подходящие, реализовать систему на основе выбранного решения и внедрить его для последующей эксплуатации.
5.1 Организация и планирование работ
Для реализации целей ВКР необходимо было выполнить задачи, показанные в таблице 5.
При организации процесса реализации данного проекта была приблизительно распланирована занятость каждого из его участников.
Далее приведен перечень работ и продолжительность их выполнения каждым из участников (научным руководителем и исполнителем).
Таблица 5 — Перечень работ и продолжительность их выполнения
Этапы работы
Исполнители
Загрузка исполнителей
Постановка целей разработки и пред- ложение возможных способов их ре- шения
НР, И
НР — 50%
И — 50%

70
Этапы работы
Исполнители
Загрузка исполнителей
Исследование существующей инфра- структуры
НР, И
НР — 10%
И — 90%
Поиск подходящих решений
НР, И
НР — 10%
И — 90%
Разработка системы на основе выбран- ного решения
И
И — 100%
Оформление пояснительной записки
И
И — 100%
Подведение итогов
НР, И
НР — 50%
И — 50%

5.2 Продолжительность этапов работ
В нашем случае оценить продолжительность этапов работа можно при помощи опытно-статистического метода экспертным способом. Ожидаемое значение продолжительности работ t
ож
находится по формуле
??????
ож
=
3∗??????
??????????????????
+2∗??????
??????????????????
5
,



(1) где t min
— минимальная продолжительность работы, дн.; t
max
— максимальная продолжительность работы, дн.
Для построения линейного графика необходимо рассчитать длительность этапов в рабочих днях, а затем перевести ее в календарные дни. Расчет продолжительности выполнения каждого этапа в рабочих днях (Т
РД
) ведется по формуле:
Т
РД
=
??????
ож
К
ВН
∗ К
Д
,



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

71
К
Д
— коэффициент, учитывающий дополнительное время на компенсацию непредвиденных задержек и согласование работ. Примем К
Д
= 1,1.
Расчет продолжительности этапа в календарных днях ведется по формуле:
Т
КД
= Т
РД
∗ Т
К
,



(3) где Т
КД
— продолжительность выполнения этапа в календарных днях;
Т
К
— коэффициент календарности, позволяющий перейти от длительности работ в рабочих днях к их аналогам в календарных днях. При пятидневной рабочей неделе Т
К
= 1,4. Результаты расчетов приведены в таблице
Таблица 6.
Таблица 6 — Трудозатраты на выполнение проекта
Этап
Исполни- тели
Продолжитель- ность работ, дни
Трудоемкость работ по исполнителям чел.- дн.
T
РД

T
КД

t
min

t
max

t
ож

НР И
НР И
1 2
3 4
5 6
7 8
9
Постановка це- лей разработки и предложение возможных спо- собов их реше- ния
НР, И
3 5
3,8 2,1 2,1 2,9 2,9
Исследование существующей инфраструктуры
НР, И
5 10 7
0,8 6,9 1,1 9,7
Поиск подходящих решений
НР, И
10 20 14 1,5 13,9 2,2 19,4
Разработка си- стемы на основе выбранного ре- шения
И
20 30 24 0
26,4 0 37
Оформление пояснительной записки
И
20 30 24 0
26,4 0 37
Подведение итогов
НР, И
1 5
2,6 1,4 1,4 2
2
Итого:
59 100 75,4 5,8 77,1 8,2 108

72
Для наглядного отображения трудозатрат участниками проекта составим был составлен линейный график работ, приведенный в таблице 7. В линейном графике закрашенной линией отмечены трудозатраты исполнителя, а прозрачной трудозатраты научного руководителя. В столбце 1 указаны номера по порядку соответствующих этапов трудовой деятельности из таблицы 6, а в столбцах 2 и 3 числовые показатели трудозатрат научным руководителем и исполнителем соответственно.
Таблица 7 — Линейный график работ
Эта п
НР
И
Февраль
Март
Апрель
Май
10 20 30 40 50 60 70 80 90 10 0
11 0
1
2
3
4
5
6
7
8
9
10 11 12 13 14
1 2,9 2,9






2 1,1 9,7






3 2,2 19,4





4 0,0 37,0





5 0,0 37,0





6 2,0 2,0






5.3 Расчет накопления готовности проекта
Цель данного пункта оценка текущих состояний (результатов) работы над проектом. Величина накопления готовности работы показывает, на сколько процентов по окончании текущего (i-го) этапа выполнен общий объем работ по проекту в целом.
Введем обозначения:
ТР
общ
. — общая трудоемкость проекта;
ТР
i
(ТР
k
) − трудоемкость i-го (k-го) этапа проекта,
?????? = 1, ??????
̅̅̅̅;

73
ТР

− накопленная трудоемкость i-го этапа проекта по его завершении;
ТР
ij
(ТР
kj
) − трудоемкость работ, выполняемых j-м участником на i-м этапе, здесь
?????? = 1, ?????? − индекс исполнителя, в нашем примере m = 2.
Степень готовности определяется формулой
СГ
??????
=
ТР
??????
Н
ТР
общ.
=

ТР
??????
??????
??????=1
ТР
общ.
=


ТР
????????????
??????
??????=1
??????
??????=1


ТР
????????????
??????
??????=1
??????
??????=1

(4)
Результаты расчетов приведены в таблице 8.
Таблица 8 — Нарастание технической готовности работы
Этап
ТР
i
, %

i
, %
Постановка целей разработки и предложение возможных способов их решения
5,0 5,0
Исследование существующей инфраструктуры
9,3 14,3
Поиск подходящих решений
18,6 32,9
Разработка системы на основе выбранного решения
31,8 64,7
Оформление пояснительной записки
31,8 96,6
Подведение итогов
3,4 100,0
5.4 Расчет сметы затрат на выполнение проекта
В состав затрат на создание проекта включается величина всех расходов, необходимых для реализации комплекса работ, составляющих содержание данной работы. Расчет сметной стоимости ее выполнения производится по следующим статьям затрат:
• материалы и покупные изделия;
• заработная плата;

74
• социальный налог;
• расходы на электроэнергию (без освещения);
• амортизационные отчисления;
• прочие (накладные расходы) расходы.
5.4.1 Расчет затрат на материалы
К данной статье расходов относится стоимость материалов, покупных изделий и других материальных ценностей, расходуемых непосредственно в процессе выполнения работ над объектом проектирования. Затраты на материалы и покупные изделия сведены в таблицу 9.
Таблица 9 — Затраты на материалы и покупные изделия
Наименование материалов и покупных изделий
Единица измерения
Количество
Цена за ед.,
Стои- мость, руб. руб.
Бумага для печати уп.
2 200 400
Ручка шариковая шт.
2 12 24
Файл-вкладыш шт.
50 2
100
Скоросшиватель шт.
3 11 33
Картридж для принтера шт.
1 2800 2800
Транспортно-заготовительные расходы
335,7
Итого
3692,7
5.4.2 Расчет заработной платы
Данная статья расходов включает заработную плату научного руководителя и исполнитель проекта, а также премии, входящие в фонд заработной платы. Затраты на заработную плату сведены в таблицу 10. В расчете учитывается, что в 2016 году, при пятидневной рабочей неделе, насчитывается
247 рабочих дней, а, следовательно, в месяце в среднем 20,58 рабочих дня.

75
Таблица 10 — Затраты на заработную плату
Исполнител ь
Оклад, руб./мес.
Среднеднев- ная ставка, руб./раб.день
Затраты времени
, раб.дни
Коэффициен т
Фонд з/платы, руб.
НР
20 776,45 1 009,55 5,80 1,62 9 485,69
И
7 483,58 363,63 77,10 1,62 45 418,57
Итого:


54 904,26
5.4.3 Расчет затрат на социальный налог
Затраты на единый социальный налог (ЕСН), включающий в себя отчисления в пенсионный фонд, на социальное и медицинское страхование, составляют 30 % от полной заработной платы по проекту, т.е. С
соц
= C
зп
*0,3. Итак, в нашем случае С
соц
= 54 904,26 * 0,3 = 16 471,28 руб.

5.4.4 Расчет затрат на электроэнергию
Данный вид расходов включает в себя затраты на электроэнергию, потраченную в ходе выполнения проекта на работу используемого оборудования, рассчитываемые по формуле:
С
эл.об
= Р
об
∗ ??????
об
∗ Ц
э
,





(5) где Р
об
— мощность, потребляемая оборудованием, кВт;
Ц
э
— тариф 1 кВт*ч; t
об
— время работы оборудования, час.
Для ТПУ Ц
Э
= 5,257 руб./квт∙час (с НДС).
Время работы оборудования вычисляется на основе итоговых данных таблицы Таблица 6 для исполнителя (T
РД
) из расчета, что продолжительность рабочего дня равна 8 часов. Коэффициент К
t в нашем случае равен 0,3.

76
??????
об
= ??????
РД
∗ 24 ∗ К
??????







(6)
Мощность, потребляемая оборудованием, определяется по формуле:
Р
ОБ
= Р
ном
∗ К
С
,



(7) где P
ном
— номинальная мощность оборудования, кВт;
K
С
— коэффициент загрузки, зависящий от средней степени использования номинальной мощности. Для технологического оборудования малой мощности K
С
= 1.
Таблица 11 — Затраты на электроэнергию технологическую
Наименование оборудования
Время ра- боты обору- дования t
ОБ
, час
Потребляемая мощность P
ОБ
, кВт
Затраты
Э
ОБ
, руб.
Персональный компьютер 555,192 0,6 1 751,19
Лазерный принтер
5 0,5 13,14
Итого:

1 764,33
5.4.5 Расчет амортизационных расходов
В статье «Амортизационные отчисления» рассчитывается амортизация используемого оборудования за время выполнения проекта. Результаты расчетов приведены в таблице 12.
Используется формула
С
АМ
=
Н
А
∗Ц
ОБ
∗??????
рф
∗??????
??????
Д
,



(8) где Н
А
— годовая норма амортизации единицы оборудования, в нашем случае берется из диапазона 2 — 3 года на основании постановления правительства РФ «О классификации основных средств, включенных в амортизационные группы», код ОКОФ 14 2894000. Примем Н
А
=1/2,5=0,4;
Ц
ОБ
— балансовая стоимость единицы оборудования с учетом ТЗР.
F
Д
— действительный годовой фонд времени работы соответствующего

77 оборудования. В нашем случае, при пятидневной рабочей неделе, в 2016 году насчитывается 247 рабочих дня, а значит F
Д
=247*8=1976 часов. t
рф
— фактическое время работы оборудования в ходе выполнения проекта, учитывается исполнителем проекта; n — число задействованных однотипных единиц оборудования.
Таблица 12 — Затраты на амортизационные отчисления
Наименование оборудования
Стоимость, руб
H
A
Время работы обору- дования t
ОБ
, час
F
Д
, час
Стоимость аморт. отч., руб
Персональный компьютер 50000 0,4 555,192 1976 5 619,35
Лазерный принтер
20000 0,4 5 1976 20,24
Итого:


5 639,60
5.4.6 Расчет прочих расходов
В статье «Прочие расходы» отражены расходы на выполнение проекта, которые не учтены в предыдущих статьях, их размер принят равными 10% от суммы всех предыдущих расходов, т.е.
С
проч.
= (С
мат
+ С
зп
+ С
соц
+ С
эл
+ С
ам
) ∗ 0,1 =
= (3692,7 + 54904,26 + 16471,28 + 1764,33 + 5639,6) ∗ 0,1 =
= 8247,22 руб.
5.4.7 Расчет общей себестоимости работы
Проведя расчет по всем статьям сметы затрат на разработку, можно определить общую себестоимость работы «Обеспечение безопасности системы управления инфраструктурой центра обработки данных ТПУ». Результаты расчета приведены в таблице 13.

78
Таблица 13 — Смета затрат на данную работу
Статья затрат
Условное обозначение
Сумма, руб.
Материалы и покупные изделия
C
мат
3 692,70
Основная заработная плата
C
зп

54 904,26
Отчисления в социальные фонды
C
соц

16 471,28
Расходы на электроэнергию
С
эл.
1 764,33
Амортизационные отчисления
C
ам

5 639,60
Прочие расходы
C
проч
8 247,22
Итого:

90 719,38
Таким образом, затраты на разработку составили C = 90 719,38 руб.
5.4.8 Расчет прибыли
Размер прибыли примем равным 20% от себестоимости проекта, таким образом она составит 18 143,88 руб.
5.4.9 Расчет НДС
НДС составляет 18% от суммы затрат на разработку и прибыли. В нашем случае это (90 719,38 + 18 143,88) * 0,18 = 19 595,39 руб.
5.4.10 Цена разработки НИР
Цена равна сумме полной себестоимости, прибыли и НДС, в нашем случае
Ц
НИР
= 90 719,38 + 18 143,88 + 19 595,39 = 128 458,64 руб.

79
5.5 Оценка экономической эффективности проекта
Основными факторами ожидаемого экономического эффекта данного проекта являются: снижение рисков и повышение эффективности при администрировании существующей инфраструктуры организации.
Количественная оценка эффективности в рамках данной работы невозможна, в виду методологической сложности и очень высокой стоимости подобного исследования. Причины обуславливающие данные эффекты изложены ниже.
Снижение рисков в контексте информационной безопасности трудно выразить количественно. Нам заранее неизвестно какого рода атаки будут выполнены на инфраструктуру и какие действия предпримет потенциальный взломщик в случае её успеха. Можно лишь предположить, что произойдет в худшем случае развития событий.
Во-первых, в случае кражи базы данных организации будет нарушена конфиденциальность персональных данных хранящихся в ней. Требование обеспечивать конфиденциальность данных накладывает федеральный закон
Российской Федерации №152-ФЗ от 27.07.2006 «О персональных данных». Лица, виновные в нарушении требований настоящего Федерального закона, несут предусмотренную законодательством Российской Федерации ответственность.
Которая может носить гражданский, уголовный, административный или дисциплинарный характер. Так статья 19.5 Кодекса об административных правонарушениях (КоАП) РФ «Невыполнение в срок законного предписания
(постановления, представления, решения) органа (должностного лица), осуществляющего государственный надзор (контроль)» предусматривает наложение штрафа в размере до 500 000 руб. и дисквалификацию должностного лица сроком до 3 лет. Статья 137 Уголовного кодекса (УК) РФ «Нарушение неприкосновенности частной жизни» предусматривает наложение штрафа в размере до 300 000 руб., исправительные работы сроком до 240 часов, арест

80 сроком до 6 месяцев. Пожалуй, самый непредсказуемый и потенциально наиболее серьезный ущерб организации может нанести ответственность по статье 24 152-ФЗ от 27.07.2006 «О персональных данных» и статье 237 Трудового кодекса РФ «Моральный вред, причинённый работнику неправомерными действиями или бездействием работодателя», которые дают физическим лицам право на возмещение морального и имущественного вреда, а также понесённых убытков. Размер возмещения будет определяться судом, и заранее он ничем не ограничен.
Во-вторых, нарушение работоспособности ключевых информационных систем организации может привести к невозможности осуществлять свою деятельность, что ставит под угрозу само её существование
В-третьих, даже в случае успешного и своевременного устранения последствий взлома информационных ресурсов, организация неизбежно теряет свою репутацию, что оказывает прямой отрицательный эффект на её конкурентоспособность, а, следовательно, и эффективность.
Результаты деятельности не планируется превращать в коммерческий продукт и использовать за пределами организации.
При этом, стек используемых технологий, и методика решения поставленной задачи могут использоваться другими организациями в качестве положительного опыта. Учитывая тот факт, что реализация подобной системы не требует покупки дополнительных аппаратных или программных средств, а влечет только трудозатраты по внедрению, можно сделать вывод о благотворном влиянии применения результатов данной работы.
5.6 Оценка научно-технического уровня НИР
Научно-технический уровень характеризует влияние проекта на уровень и динамику обеспечения научно-технического прогресса в данной области. Для оценки научной ценности, технической значимости и эффективности, планируемых и выполняемых НИР, используется метод балльных оценок.

81
Балльная оценка заключается в том, что каждому фактору по принятой шкале присваивается определенное количество баллов — таблица Таблица 14.
Обобщенную оценку проводят по сумме баллов по всем показателям. На ее основе делается вывод о целесообразности НИР.
Сущность метода заключается в том, что на основе оценок признаков работы определяется интегральный показатель (индекс) ее научно-технического уровня по формуле:
??????
НТУ
= ∑
??????
??????
∗ ??????
??????
,
3
??????=1



(9) где I
НТУ
— интегральный индекс научно-технического уровня;
R
i
— весовой коэффициент i-го признака научно-технического эффекта;
n
i
— количественная оценка i-го признака научно-технического эффекта, в баллах.
Таблица 14 — Оценка научно-технического уровня НИР
Значимость
Фактор
НТУ
Уровень фактора
Выбран- ный балл
Обоснование выбран- ного балла
0.4
Уровень новизны
Относи- тельно но- вая
4
Используются уже из- вестные сведения для увеличения эффектив- ности
0.1
Теоретиче- ский уро- вень
Разработка способа
6
Система разработана и реализована
0.5
Возмож- ность реа- лизации
В течение первых лет
10
Для применения на практике необходимо меньше 1 года
Отсюда интегральный показатель научно-технического уровня для нашего проекта составляет I
нту
= 0,4*4 + 0,1*6 + 0,5*10 = 1,6 + 0,6 + 5 = 7,2.
Интегральный показатель равен 7.2. Таким образом, данный проект имеет средний уровень научно-технического эффекта.
1   2   3   4   5


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал