Файл: Отчет по производственной практике пм. 03. Участие в интеграции программных модулей.docx
Добавлен: 07.11.2023
Просмотров: 165
Скачиваний: 8
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Разрешение на доступ к конкретным объектам базы данных сохраняется в файле рабочей группы.
Файл рабочей группы содержит данные о пользователях группы и считывается во время запуска. Файл содержит следующую информацию: имена учетных записей пользователей, пароли пользователей, имена групп, в которые входят пользователи.
К дополнительным средствам защиты баз данных можно отнести следующие средства:
встроенные средства контроля значений данных в соответствии с типами:
повышение достоверности вводимых данных:
обеспечения целостности связей таблиц:
организации совместного использования объектов базы данных в сети.
Описанные выше методы и способы являются основополагающими, однако их использование не гарантирует полной сохранности данных. Для повышения уровня безопасности информации в базе данных рекомендуется использование комплексных мер.
1.9 Стандартизация защищенности программ
Общие критерии оценки защищённости информационных технологий, Общие критерии, ОК (англ. Common Criteria for Information Technology Security Evaluation, Common Criteria, CC) - российский и международный стандарт по компьютерной безопасности. В отличие от стандарта FIPS 140, Common Criteria не приводит списка требований по безопасности или списка особенностей, которые должен содержать продукт. Вместо этого он описывает инфраструктуру (framework), в которой потребители компьютерной системы могут описать требования, разработчики могут заявить о свойствах безопасности продуктов, а эксперты по безопасности определить, удовлетворяет ли продукт заявлениям. Таким образом, Common Criteria позволяет обеспечить условия, в которых процесс описания, разработки и проверки продукта будет произведён с необходимой скрупулёзностью.
Стандарт содержит два основных вида требований безопасности: функциональные, предъявляемые к функциям безопасности и реализующим их механизмам, и требования доверия, предъявляемые к технологии и процессу разработки и эксплуатации.
Функциональные требования сгруппированы на основе выполняемой ими роли или обслуживаемой цели безопасности, всего 11 функциональных классов (в трёх группах), 66 семейств, 135 компонентов.
Первая группа определяет элементарные сервисы безопасности:
FAU - аудит, безопасность (требования к сервису, протоколирование и аудит);
FIA - идентификация и аутентификация;
FRU - использование ресурсов (для обеспечения отказоустойчивости).
Вторая группа описывает производные сервисы, реализованные на базе элементарных:
FCO - связь (безопасность коммуникаций отправитель-получатель);
FPR - приватность;
FDP - защита данных пользователя;
FPT - защита функций безопасности объекта оценки.
Третья группа классов связана с инфраструктурой объекта оценки:
FCS - криптографическая поддержка (обслуживает управление криптоключами и крипто-операциями);
FMT - управление безопасностью;
FTA - доступ к объекту оценки (управление сеансами работы пользователей);
FTP - доверенный маршрут/канал;
Требования гарантии безопасности (доверия) - требования, предъявляемые к технологии и процессу разработки и эксплуатации объекта оценки. Разделены на 10 классов, 44 семейства, 93 компонента, которые охватывают различные этапы жизненного цикла.
Первая группа содержит классы требований, предшествующих разработке и оценке объекта:
APE - оценка профиля защиты;
ASE - оценка задания по безопасности.
Вторая группа связана с этапами жизненного цикла объекта аттестации:
ADV - разработка, проектирование объекта;
ALC - поддержка жизненного цикла;
ACM - управление конфигурацией;
AGD - руководство администратора и пользователя;
ATE - тестирование;
AVA - оценка уязвимостей;
ADO - требования к поставке и эксплуатации;
АMA - поддержка доверия-требования, применяется после сертификации объекта на соответствие общим критериям.
1.10 Сертификация и порядок её проведения
Основной целью сертификации технологий проектирования и производства систем и программных средств является защита интересов пользователей, государственных и ведомственных интересов на основе контроля качества продукции, обеспечения их высоких потребительских свойств, повышения эффективности затрат в сфере их производства, эксплуатации и сопровождения, повышения объективности оценок характеристик и обеспечения конкурентоспособности конечного продукта. Проведение сертификации систем качества предприятия обычно планируется для достижения одной или нескольких целей:
определения соответствия или несоответствия элементов
системы качества установленным требованиям производства;
определения эффективности внедренной системы качества
предприятия с точки зрения соответствия поставленным целям для
обеспечения качества продукции;
обеспечения возможности предприятию улучшить свою сис-
тему качества;
определения соответствия системы качества производства
регламентирующим требованиям.
Обязательная сертификация необходима для программных продуктов и их производства, выполняющих особо ответственные функции, в которых недостаточное качество, ошибки или отказы могут нанести большой ущерб или опасны для жизни и здоровья людей. Этот ущерб может определяться степенью безопасности применения комплексов программ в авиации, для управления в космосе, в атомной энергетике, в военных системах; или большими экономическими потерями в результате низкого качества функционирования ПС в системах государственного управления, в финансовых, банковских, транспортных системах. В подобных системах обязательная сертификация программных продуктов способствует значительному снижению риска заказчика и повышению безопасности функционирования программного продукта у потребителя до необходимого уровня. В этих случаях разработчики и поставщики программного продукта обязаны подвергать свои изделия сертификации на соответствие требованиям качества и безопасности для получения разрешения компетентных органов на их реальную эксплуатацию и применение по прямому назначению.
Добровольная сертификация применяется с целью повышения конкурентоспособности продукции, расширения сферы ее использования и получения дополнительных экономических преимуществ. Экономическими целями сертификации могут быть большие тиражи изделий при производстве, большая длительность жизненного цикла с множеством версий, снижение налогов за высокое качество, увеличение прибыли разработчиков и поставщиков программного продукта, сокращение рекламаций пользователей. Результаты сертификации должны оправдывать затраты на ее проведение вследствие получения пользователями продукции более высокого и гарантированного качества при некотором повышении ее стоимости. Таким сертификационным испытаниям подвергаются компоненты операционных систем и пакеты прикладных программ широкого применения, повышение гарантии качества, которое выгодно как для поставщиков, так и для пользователей программного продукта. В этих случаях разработчики и поставщики добровольно предоставляют программные средства для сертификации с учетом экономических оценок выгодности ее проведения для их продуктов.
Порядок проведения сертификации в России установлен постановлением Госстандарта России от 21 сентября 1994 г. № 15 по отношению к обязательной сертификации (в том числе и импортируемой продукции), но может применяться и при добровольной сертификации. Для систем сертификации однородной продукции с учетом ее особенностей допускается разработка соответствующего порядка.
. Этап заявки на сертификацию заключается в выборе заявителем органа по сертификации, способного провести оценку соответствия интересующего его объекта. Это определяется областью аккредитации органа по сертификации.
. Этап оценки соответствия имеет особенности в зависимости от объекта сертификации. Применительно к продукции он состоит из отбора и идентификации образцов изделий и их испытаний. Образцы должны быть такими же, как и продукция, поставляемая потребителю. Образцы выбираются случайным образом по установленным правилам из готовой продукции.
Этап оценки системы качества на предприятии начинается с подготовки в органе по сертификации. При подготовке к проверке и оценке системы качества выполняют следующие работы:
составляют программу проверки;
распределяют обязанности между членами комиссии в соответствии с программой проверки;
подготавливают рабочие документы;
согласуют программы проверки с проверяемой организацией.
Составление акта, где указываются результаты проверки, выводы и рекомендации комиссии, проводят по окончании работ по оценке соответствия.
На этом этап практической оценки соответствия при сертификации систем качества заканчивается.
. Этап анализа практической оценки соответствия объекта сертификации установленным требованиям заключается в рассмотрении результатов испытаний, экзамена или проверки системы качества в органе по сертификации.
При сертификации систем качества анализ результатов оценки соответствия проводится на основании акта о проверке. Выводы по акту сводятся к одному из трех вариантов:
) система полностью соответствует заявленному стандарту;
) система в целом соответствует стандарту, но обнаружены отдельные малозначительные несоответствия по элементам системы качества;
) система содержит значительные несоответствия.
. Решение по сертификации сопровождается выдачей сертификата соответствия заявителю или отказом в нем. При положительных результатах испытаний (проверок), предусмотренных схемой сертификации, и экспертизы представленных документов орган по сертификации оформляет сертификат соответствия, регистрирует его и выдает лицензию на право применения знака соответствия. Этим знаком маркируется продукция или документация на услуги, прошедшая сертификацию..
. Инспекционный контроль за сертифицированным объектом проводится органом, выдавшим сертификат, если это предусмотрено схемой сертификации. Он проводится в течение всего срока действия сертификата, обычно один раз в год в форме периодических проверок. В комиссии органа по сертификации при инспекционном контроле могут участвовать специалисты территориальных органов Ростех-регулирования, представители обществ потребителей и других заинтересованных организаций. Внеплановые проверки осуществляются при наличии информации о претензиях к качеству продукции и услуг, а также при существенных изменениях в конструкции сертифицированного изделия, технологии оказания услуг или организационной структуре предприятия, влияющих на процессы системы качества.
1.11 Подготовка к эксплуатации
Все работы данного этапа уже проводятся на территории Заказчика и включают в себя установку и настройку всех компонентов системы в информационной среде Заказчика, проведение предварительного тестирования, разработку пользовательской документации, обучение пользователей, загрузку исходных данных, проведение испытаний системы в соответствии с программой и методикой испытаний и прочие подготовительные работы.
К моменту окончания всех подготовительных работ должен быть разработан и утвержден регламент эксплуатации системы. Регламент, в частности, должен определять пользователей и их роли в системе, в соответствии с их должностными обязанностями.
Сопровождение (поддержка) программного обеспечения - процесс улучшения, оптимизации и устранения дефектов программного обеспечения после передачи в эксплуатацию. Сопровождение программного обеспечения - это одна из фаз жизненного цикла программного обеспечения, следующая за фазой передачи программного обеспечения в эксплуатацию. В ходе сопровождения в программу вносятся изменения, с тем, чтобы исправить обнаруженные в процессе использования дефекты и недоработки, а также для добавления новой функциональности, с целью повысить удобство использования и применимость программного обеспечения.
2. ПРАКТИЧЕСКАЯ ЧАСТЬ
2.1 Техническое задание
2.1.1 Основание для разработки
Основанием для разработки является задание на производственную практику ПМ.03. Участие в интеграции программных модулей от 30 января 2017 года.
Наименование работы: Автоматизированная информационная система “Учет работы ОЗНА”.
2.1.2 Назначение разработки
Автоматизированная информационная система “Учёт работы «АК ОЗНА»” предназначена для сбора сведений о выполненной работе за определённый промежуток времени и ведения статистики. Пользователями программы выступают бухгалтера компании, отдел учёта, отдел приема и оформления заявок. Выполнение заявок осуществляется на основании договоров о сотрудничестве, в которых оговариваются условия и стоимость работ. Менеджер ведёт учёт полученных заявок, где указывается номер по порядку, срок выполнения, наименование заявки или поломки, фамилия заказчика.
2.1.3 Требования к программе
2.1.3.1 Требования к функциональным характеристикам
Автоматизированная информационная система “Учет работы ОЗНА” должна обеспечивать выполнение функций:
ввод, хранение, поиск и обработку информации по производству;