Этапы сертификации

dev / / Документирование и сертификация
  1. Заявитель (разработчик либо другая компания, заинтересованная в проведении сертификации) подает в федеральный орган (ФСБ, ФСТЭК или Минобороны) по сертификации заявку на проведение сертификационных испытаний некоторого продукта.
  2. Федеральный орган определяет аккредитованную испытательную лабораторию и орган по сертификации.
  3. Испытательная лаборатория совместно с заявителем проводит сертификационные испытания. Если в процессе испытаний выявляются те или иные несоответствия заявленным требованиям, то они могут быть устранены заявителем в рабочем порядке, что и происходит в большинстве случаев, либо может быть принято решение об изменении требований к продукту, например, о снижении класса защищенности. Возможен вариант, когда сертификационные испытания завершаются с отрицательным результатом. Наиболее нашумевшим в прессе примером можно назвать случай, когда испытательная лаборатория НИИ ВМФ после года проверок выдала отрицательное сертификационное заключение на программные изделия специального назначения. Известны как минимум пять случаев, когда определенные версии ОС и СУБД не смогли получить сертификат на отсутствие недекларированных возможностей по причине потери части исходного кода старых модулей. Если посмотреть реестр ФСТЭК, то можно заметить, что ряд программных систем защиты (например, СУБД Oracle и система безопасности приложений IBM Guardium) получили сертификаты лишь на соответствие ТУ, а не на соответствие руководящему документу Гостехкомиссии — это значит, что орган по сертификации посчитал, что не все требования руководящего документа подтверждены при испытаниях.
  4. Материалы испытаний передаются в орган по сертификации, который проводит их независимую экспертизу. Как правило, в экспертизе участвуют не менее двух экспертов, которые независимо друг от друга подтверждают корректность и полноту проведения испытаний.
  5. Федеральный орган по сертификации на основании заключения органа по сертификации оформляет сертификат соответствия. Надо сказать, что в случае выявления каких-либо несоответствий федеральный орган может провести дополнительную экспертизу с привлечением экспертов из различных аккредитованных лабораторий и органов.

Что такое добровольная сертификация?

dev / / Документирование и сертификация

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

  • Больший тираж изделия при производстве
  • Большая длительность жизненного цикла
  • Снижение налогов за высокое качество
  • Сокращение рекламации пользователей

Что такое обязательная сертификация?

dev / / Документирование и сертификация

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

Разработчик и поставщик программного продукта обязаны подвергать свои изделия сертификации на соответствие требованиям качества и безопасности.

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

Сертификация программных средств. Основные определения

dev / / Документирование и сертификация

Сертификация – процедура, подтверждающая соответствие программного продукта требованиям стандарта.

Виды сертификации:

  • Добровольная
  • Обязательная

Что касается документов, на соответствие которым проводятся сертификационные испытания, то они практически идентичны во всех системах сертификации. Существуют два основных подхода к сертификации – и соответственно два типа нормативных документов.

Функциональное тестирование средств защиты информации, позволяющее убедиться в том, что продукт действительно реализует заявленные функции. Это тестирование чаще всего проводится на соответствие конкретному нормативному документу – например, одному из руководящих документов Гостехкомиссии России. Такие документы установлены, например, для межсетевых экранов и средств защиты от несанкционированного доступа. Если же не существует документа, которому сертифицируемый продукт соответствовал бы в полной мере, то функциональные требования могут быть сформулированы в явном виде – например, в технических условиях, или в виде задания по безопасности (в соответствии с положениями стандарта ГОСТ Р 15408).

Структурное тестирование программного кода на отсутствие недекларированных возможностей. Классическим примером недекларированных возможностей являются программные закладки, которые при возникновении определенных условий инициируют выполнение не описанных в документации функций, позволяющих осуществлять несанкционированные воздействия на информацию (по ГОСТ Р 51275-99). Выявление недекларированных возможностей предполагает проведение серии тестов исходных текстов программ, предоставление которых является необходимым условием для возможности проведения сертификационных испытаний.

Метод гаммирования на PHP

dev / / PHP

Гамми́рование, или Шифр XOR, — метод симметричного шифрования, заключающийся в «наложении» последовательности, состоящей из случайных чисел, на открытый текст. Последовательность случайных чисел называется гамма-последовательностью и используется для зашифровывания и расшифровывания данных.

function gamma_encryption($str, $passw = '') {
   $salt = 'jEJerBV3xg';
   $len = strlen($str);
   $gamma = '';
   $n = $len > 100 ? 8 : 2;
   while (strlen($gamma) < $len) {
      $gamma .= substr(pack('H*', sha1($passw . $gamma . $salt)), 0, $n);
   }
   return $str ^ $gamma;
}

Запуск Hashicorp Vault в Docker Compose

dev / / Docker

docker-compose.yml

version: '3.9'

services:

  vault:
    image: vault:1.9.4
    container_name: vault
    volumes:
      - ./config:/vault/config
      - ./policies:/vault/policies
      - ./data:/vault/data
    ports:
      - 8200:8200
    environment:
      - VAULT_ADDR=http://0.0.0.0:8200
      - VAULT_API_ADDR=http://0.0.0.0:8200
      - VAULT_ADDRESS=http://0.0.0.0:8200
    cap_add:
      - IPC_LOCK
    command: vault server -config=/vault/config/vault.json
    
  vault-ui:
    image: djenriquez/vault-ui:2.3.0
    container_name: vault-ui
    ports:
      - 8000:8000
    environment:
      - 'VAULT_URL_DEFAULT=http://vault:8200'
      - VAULT_AUTH_DEFAULT=GITHUB

Файл располагается в корневом каталоге.

Файл vault.json:

{                                    
  "listener":  {                     
    "tcp":  {                        
      "address":  "0.0.0.0:8200",  
      "tls_disable":  "true"         
    }                                
  },                                 
  "backend": {                       
    "file": {                        
      "path": "/vault/file"          
    }                                
  },                                 
  "default_lease_ttl": "168h",       
  "max_lease_ttl": "0h",
  "api_addr": "http://0.0.0.0:8200"
}

Выполнить сборку контейнера и запустить можно при помощи команды:

docker-compose up --build -d
vaultСкачать

ГОСТ 19.503–79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению

dev / / Документирование и сертификация

Руководство системного программиста должно содержать следующие разделы:

  1. Общие сведения о программе
  2. Структура программы
  3. Настройка программы
  4. Проверка программы
  5. Дополнительные возможности
  6. Сообщения системному программисту

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

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

В разделе Структура программы приводятся сведения о структуре программы, ее составных частях и связях с другими программами.

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

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

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

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

ГОСТ 19.402–78 ЕСПД. Описание программы

dev / / Документирование и сертификация

Данный стандарт определяет состав и требования к содержанию программного документа «Описание программы». Описание программы включает:

  • Общие сведения
  • Функциональное назначение
  • Описание логической структуры
  • Используемые технические средства
  • Вызов и загрузка
  • Входные данные
  • Выходные данные

В разделе Общие сведения указывают:

  • Обозначение и наименование программы
  • Программное обеспечение, необходимое для функционирования программы
  • Языки программирования, на которых написана программа

Раздел Функциональное назначение должен отражать классы решаемых задач и/или назначение программы, сведения о функциональных ограничениях на применение.

При описании логической структуры должны быть отражены:

  • Алгоритм программы
  • Используемые методы
  • Структура программы с описанием функций составных частей и связей между ними
  • Связи программы с другими программами

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

При описании раздела Вызов и загрузка указывают способ вызова программы с соответствующего носителя данных и входные точки в программу.

Раздел Входные данные отражает:

  • Характер, организацию и предварительную подготовку входных данных
  • Формат, описание и способ кодирования входных данных

Раздел Выходные данные отражает:

  • Характер и организацию выходных данных
  • Формат, описание и способ кодирования выходных данных

Способы шифрования паролей к базам данных в конфигурационном файле на примере Node.js

dev / / Node.js

Однажды меня спросили:

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

Привожу пару мыслей на этот счет.

Настройка прав доступа к файлу средствами Linux

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

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

Плюсы:
+ В конфигурационный файл удобно вносить изменения.

Минусы:
— У пользователя root в любом случае есть все права на конфигурационный файл.

Vault by HashiCorp

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

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

Минусы:
— Если файл зашифрован, но рядом лежит ключ для расшифровки, то пароль будет все равно извлечен.

Обфускация, напр. через NPM-пакет javascript-obfuscator

Тот же JS, но в неудобочитаемом виде.

Плюсы:
+- Не является шифровальщиком, но позволяет скрыть какие-то алгоритмы и логику работы программы.

Минусы:
— В обфусцированном файле при детальном просмотре пароли видны в явном виде.

Инициализация приложения из другого источника

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

Плюсы:
+ Пароль не хранится на боевом сервере.

Минусы:
— Нужен какой-то скрипт, который будет производить запуск/перезапуск приложения и подчищать «хвосты».

Преобразование JavaScript в байткод, напр. через NPM-пакет bytenode

Байт-код (англ. bytecode) — стандартное промежуточное представление, в которое может быть переведена компьютерная программа автоматическими средствами. По сравнению с исходным кодом, удобным для создания и чтения человеком, байт-код — это компактное представление программы, уже прошедшей синтаксический и семантический анализ. В нём в явном виде закодированы типы, области видимости и другие конструкции. С технической точки зрения байт-код представляет собой машинно-независимый код низкого уровня, генерируемый транслятором из исходного кода.

Плюсы:
+ Нет ключа дешифровки.

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

Запуск Jenkins в Docker Compose

dev / / Docker

docker-compose.yml

version: '3'
services:
  jenkins:
    image: jenkins:2.60.3
    container_name: jenkins
    # uncomment for docker in docker
    # run http://localhost:8080/restart (An error occurred during installation: No such plugin: cloudbees-folder)
    privileged: true
    user: root
    volumes:
        # enable persistent volume (warning: make sure that the local jenkins_home folder is created)
        - ./jenkins_home:/var/jenkins_home
        # mount docker sock and binary for docker in docker (only works on linux)
        - ./var/run/docker.sock:/var/run/docker.sock
        - ./usr/bin/docker:/usr/bin/docker
    ports:
      - 8113:8080

Файл располагается в корневом каталоге.

Выполнить сборку контейнера и запустить можно при помощи команды:

docker-compose up --build -d
jenkinsСкачать