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

Question

[Дмитрий Баскаков]

Задача: сделать админ-панель и личный кабинет пользователя в котором будет много конфиденциальной информации по типу сканов важных документов

На данный момент, в голову пришло 2 решения в формате 2х серверов и 3х:

• 2 сервера: админ-панель на первом и БД с API на втором
  
• 3 сервера: админ-панель на первом, API на втором, БД на третьем
  

Со стороны кода, в голову пришли такие варианты:

• Очень плохая идея. Делать запросы к API на стороне сервера
  
• Делать API общедоступным и реализовать на нем авторизацию для получения данных
  

Так вот, какие есть ещё варианты и как лучше сделать?

Comments

[Drno]

Очень странная логика. Зачем эти вещи выводить на разные сервера? Чего этим хотим добиться?)

[Дмитрий Баскаков]

Drno, если бы я в этом всем разбирался, то обязательно бы ответил

[Drno]

Дмитрий Баскаков, я бы делал так.
сам портал для юзером на отдельном серваке, чтобы он был независим

БД и API можете размещать на 1 серваке

ну и в идеале какой то дублирующий сервер, если надо чтоб это работало безостановочно

ну и где то надо бэкапы хранить ) можно на дублирующем серваке

[Drno]

Dr. Bacon, ну идея в том, чтоб ЛК работал независимо, а отдача данных \ сервисов не была привязана к тому же серваку.

в случае проблем с API или что то с этом роде, в ЛК человек попадет хоть.... ну типо написать письмо в тех по или типа того

[Drno]

Dr. Bacon, ну так то да.. тоже логично

Answer 1

[Василий Банников]

"быстрая и простая" - всё закинуть на один мощный сервер.
Безопасность системы от количества серверов никак не зависит.

Если вы уже посчитали, что вам нужно несколько серверов, то:
1. Доступ к ним из интернета не должен быть (вернее должен быть только к фронту и бэку)
2. Везде обязательно должны стоять не дефолтные пароли
3. Сами пароли желательно должны храниться в каком-нибудь безопасном хранилище типа HC Vault
4. Обязательно должна быть какая-то система аутентификации пользователя и какая-нибудь ролевая/правовая система, чтобы обычный пользователь ну никак не могут сделать что-то, что ему нельзя.

Из коммуникаций у тебя даже в самой большой схеме получается что-то такое:
1. Пользователь (браузер на компьютере пользователя) загружает фронтовые файлы с Сервера 1, который раздаёт статику
2. С браузера посылается запрос к API на сервере 2
3. API с сервера 2 посылает запрос к БД.
N. Всё то же самое в обратном порядке для отправки ответа, кроме Сервера 1, который раздаёт статику.

Тоесть тут вообще никаких неочевидных проблем с выбором способа коммуникации вообще быть не должно.

А для надёжность стоит хотя бы по одной копии каждого сервиса сделать.

PS: ничего плохого в делании API Закрытым и server-server коммуникации нет.

Answer 2

[ewgenc]

Падает сервер с БД, ваши действия в дальнейшем? Резервирования мощностей нет, сервера под бекапы критически важных данных нет, репликации данных нет. Безопасное хранение пользовательских данных как будете реализовывать?

Comments

[Дмитрий Баскаков]

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

Касательно, безопасного хранения, доступ к файлам будет не прямой, а через .php скрипты, которые будут проверять наличие прав у пользователя на данный файл. Сами файлы будут хранится на сервере с API

Данные в БД будут шифроваться Laravel через касты

[Дмитрий Баскаков]

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

[ewgenc]

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

[Дмитрий Баскаков]

ewgenc, спасибо за совет. Что-то более вменяемое и полезное можете сказать?

[ewgenc]

Чтобы собирать, хранить и обрабатывать ПДн, нужно соблюдать 152-ФЗ:

Зарегистрироваться в Роскомнадзоре, как оператор.
Запрашивать разрешение на сбор и обработку данных у субъектов и не собирать лишнее.
Отвечать на обращения субъектов и предоставляете всю информацию.
Собирать и хранить информацию только для достижения определенных целей в определенный срок.
Хранить и защищать ПДн по закону, обеспечивать сохранность, тайну и точность данных, не передавая третьим лицам. А если передавать, то только с документальным подтверждением и только аттестованным.
Уточнять, блокировать или уничтожать ПДн по заявлению субъектов или когда достигли целей.

Это даже не верхушка айсберга, так, первый ответ на запрос в Гугл о хранении ПД.

[Дмитрий Баскаков]

ewgenc, это правовая сторона вопроса, а мне интересует программная, инфраструктурная

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

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

[Дмитрий Баскаков]

ewgenc, Если нет возможностей сформулировать ответ на данный вопрос, то, возможно не стоит вкидывать всё то что не относится к вопросу. Звучит логично, как по мне

[ewgenc]

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

[Дмитрий Баскаков]

ewgenc, Спасибо, вот это уже по делу

[Василий Банников]

Дмитрий Баскаков, "быстрая и простая" - всё закинуть на один мощный сервер.

Answer 3

[Dimonchik]

два сервера
увы, в одном ДЦ/стойке - иначе пинг будет мерзкий

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

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

начинаешь работу

а уже потом наворачиваешь на все это бекапы и т.п.