Лучшая архитектура для веб-приложения с конфиденциальными данными - PullRequest
Новая
       41

Лучшая архитектура для веб-приложения с конфиденциальными данными

0 голосов
/ 18 апреля 2019

Мне нужно разработать веб-приложение, содержащее медицинскую информацию. Только сотрудники организации должны иметь доступ к данным в офисе и на ходу. VPN уже на месте. Локальное управление серверами передается компании с ограниченными знаниями по работе веб-серверов. Тем не менее, клиент очень обеспокоен размещением любых данных в облаке.

Как лучше всего спроектировать приложение (Angular, Python backend, база данных) для защиты данных?

Вот варианты, о которых я думал раньше:

  1. Размещайте все в помещении за брандмауэром, пользователям придется использовать VPN для входа в систему. Pro: максимально безопасно. Против: их хостинг не будет таким дешевым и эффективным, как в облаке.
  2. Разместите приложение Angular в облаке, серверную часть Python и базу данных на месте. Статический IP-адрес может использоваться для приложения Angular, а межсетевой экран, расположенный поверх серверной части, может фильтровать весь трафик, который не поступает с этого IP-адреса, для обеспечения безопасности поверх аутентификации пользователя. Pro: более простое развертывание для изменений внешнего интерфейса, доступ без использования VPN возможен, меньше проблем с хостингом, пароль к базе данных никогда не достигнет облака. Против: размещение бэкэнда в помещении все еще будет проблемой для компании с ограниченным опытом в этой области.
  3. Разместите приложение Angular и серверную часть Python в облаке со статическим IP-адресом. База данных находится в помещении, и брандмауэр фильтрует весь трафик, который не поступает из бэкэнда Python. Pro: более простое развертывание, более дешевый и надежный хостинг. Против: пароль для подключения к базе данных лежит в облаке.

1 Ответ

1 голос
/ 23 апреля 2019

Понятно, что, хотя облачная инфраструктура от стандартных поставщиков, таких как AWS, Azure, GCP, стала очень безопасной, некоторым компаниям все еще не удобно размещать свои данные в облаке, или они могут быть связаны юридическими условиями, из-за которых они не может поместить свои данные в облако. Общая практика в таких случаях - полностью работать с командой для управления веб-серверами. Другим вариантом может быть развертывание локального облачного решения с использованием docker-compose, где образы докеров приложений и баз данных размещаются либо в личной учетной записи в Docker Hub, либо в частном реестре Docker в помещении. Однако кому-то все еще нужно будет настроить и управлять средой docker-compose. Если этот подход используется, когда клиент готов перейти в облако, это будет легко. Надеюсь, что это имеет смысл.

...