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

Обеспечение безопасности конфигурационных файлов

Для обеспечения безопасности конфигурационных файлов необходимо запретить просмотр/редактирование конфигурационных файлов /opt/<название сервиса>/application.properties всем пользователям, кроме root, командой:

chmod 700 <путь к файлу/директории>

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

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

Безопасная авторизация

По умолчанию для авторизации на кассовом сервере используются:

  • логин: admin,
  • пароль: admin.

Для возможности безопасной авторизации необходимо:

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

  3. Изменить логин и пароль на кассовом сервере для каждой учетной записи.

  4. Для нужных сервисов указать новый логин и пароль в конфигурационных файлах:

Авторизация по REST

Для авторизации по REST используются логин и пароль пользователя, созданного на кассовом сервере. 

Для возможности безопасной авторизации необходимо:

  1. На кассовом сервере в настройках включить аутентификацию в REST API. 

  2. Указать логин и пароль во всех сервисах с авторизацией по REST, которые установлены на отдельную машину (для доверенных узлов аутентификация выполняется автоматически).
    Указанные в конфигурационном файле логин (rest.user) и пароль (rest.password) будут использованы для авторизации по REST при отправке запросов на кассовый сервер. Если пользователь с таким логином и паролем существует на кассовом сервере, то сервис должен авторизоваться без ошибок.

    Пример настройки логина и пароля для сервисов с авторизацией по REST 
    rest.port=38051
rest.host=localhost
rest.user=admin1
rest.password=admin1

Безопасное подключение к БД

Изменить данные для подключения к БД (например, имя пользователя или хост). Для этого в /opt/artixcs-rest/application.properties необходимо добавить настройки (если по умолчанию они там отсутствуют):

Список основных сервисов, имеющих настройки подключения к БД:

  • artixcs-rest (mongodb, mysql, postgresql),

  • artixcs-clickhouse-rest (mysql, postgresql),

    Начиная с версии КС #64 вместо сервиса artixcs-clickhouse-rest используется сервис artixcs-sales-rest.

  • artixcs-sales-rest (mysql, postgresql),

  • сервис обмена (nes),

  • сервис tomcat8-artix,

  • artixcs-datatransfer (mysql, mssql),

  • artixcs-counters (postgresq),

  • artixcs-undercut-asset,

  • artixcs-online-card,

  • accrual-bonus (доступ к БД счетчиков),

  • artixcs-sales-ws,

  • сервисы лояльности:

    • artixcs-accounting-coupons,

    • artixcs-accounting-bonuses,

    • artixcs-accounting-bonuses-certificates,

    • artixcs-accounting-certificates.

Пример настройки для mysql
mysql.host=<хост>
mysql.port=<порт>
mysql.user=<логин>
mysql.password=<пароль>

В пароле для БД MySQL не рекомендуется использовать символы:

  • {,
  • },
  • №.
Пример настройки для postgresql
postgresql.host=<хост>
postgresql.port=<порт>
postgresql.user=<логин>
postgresql.password=<пароль>

Такой подход работает для:

    • сервисов artixcs-rest,

    • сервисов лояльности:
      • artixcs-accounting-coupons,
      • artixcs-accounting-bonuses,
      • artixcs-accounting-bonuses-certificates,
      • artixcs-accounting-certificates.

P.S. Также для более безопасной передачи данных на КЦ реализована возможность работы по протоколу https с отправкой https-запросов:

Ограничение доступа к базам данных

MySQL

Ограничить доступ к БД можно несколькими способами:

  • использовать ролевую политику (рекомендованный способ):

    Пример
    REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'netroot'@'%';
SHOW GRANTS for `netroot`@`%`;
+-------------------------------------+
| Grants for netroot@%                |
+-------------------------------------+
| GRANT USAGE ON *.* TO `netroot`@`%` |
+-------------------------------------+
1 row in set (0.00 sec)

    Видно, что прав у пользователя с другого хоста нет (USAGE подразумевает отсутствие прав). При попытке подключиться с другого хоста будет выведена ошибка:
    mysql> use artixcsAll;
ERROR 1044 (42000): Access denied for user 'netroot'@'%' to database 'artixcsAll'
  • использовать в конфигурационном файле mysql настройку bind-address:
    • если требуется доступ извне, то необходимо записать в настройку значение 0.0.0.0,
    • если доступ к БД извне не требуется (контур локальный), то в настройку необходимо записать значение 127.0.0.1.

Mongo

В целом процесс аналогичен описанному в подразделе MySQL. Чтобы ограничить доступ с других хостов, можно:

  • указать в конфигурационном файле /etc/mongod.conf в настройке bindIp = 127.0.0.1 (localhost),
  • использовать ролевую политику.
Пример
  1. Создадим пользователя qwerty / qwerty с правами только на чтение.

  2. В конфигурационном файле mongo укажем:

    security:
  authorization: enabled
  3. Перезапустим сервис.

  4. Зайдем с указанием пользователя:

    mongo -authenticationDatabase artixcs -u qwerty -p  --host 192.169.11.11 --port 27017


  5. Добавим произвольную запись:

    db.getCollection('serverInfo').insertOne({"versionRest": 192})

    Получим ошибку:

    WriteCommandError({
        "ok" : 0,
        "errmsg" : "not authorized on artixcs to execute command { insert: \"serverInfo\", ordered: true, $db: \"artixcs\" }",
        "code" : 13,
        "codeName" : "Unauthorized" 
})

  6. Для подключения кассового сервера к защищенной MongoDB необходимо указать учетные данные в конфигурационном файле /opt/artixcs-rest/application.properties:

    #Mongo
################################################################################################
#           Подключение к СУБД Mongo для КС
################################################################################################
#spring.data.mongodb.host=${mongo.host:localhost}
spring.data.mongodb.host=192.169.11.11
spring.data.mongodb.port=27017
spring.data.mongodb.database=artixcs
spring.data.mongodb.authentication-database=admin
spring.data.mongodb.username=qwerty
spring.data.mongodb.password=qwerty

PostgreSQL

В целом процесс аналогичен описанному в подразделе MySQL:

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

Ограничение доступа к базам данных через фаервол

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

Для управления доступом к БД можно использовать настройки фаервола. Для этого необходимо:

  1. Добавить правило, разрешающее доступ для localhost:

    iptables -I INPUT -p tcp -s 127.0.0.1 --dport 3306 -j ACCEPT

  2. Запретить всем доступ к порту 3306:

    iptables -A INPUT -p tcp --dport 3306 -j DROP

  3. При необходимости в начало цепочки добавить правило, разрешающее доступ избранным ip:

    iptables -I INPUT -p tcp -s 192.169.11.11 --dport 3306 -j ACCEPT

В результате получится таблица с правилами для нужных ip:

1    ACCEPT     tcp  --  192.169.11.11        anywhere             tcp dpt:mysql
2    ACCEPT     tcp  --  192.169.11.111       anywhere             tcp dpt:mysql
3    DROP       tcp  --  anywhere             anywhere             tcp dpt:mysql
  • No labels