rPman

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

1. Ты физически защищаешь сервер от доступа злоумышленника и шифруешь данные на случай если доступ все же они получат
   Этот путь подразумевает буквально, сервер в сейфе, а для обслуживания к нему катается физически надежный человек, почти все датацентры предоставляют закрытые защищенные помещения для этого. Этот способ самый простой для реализации но самый дорогой.
   
2. Обфусцируешь доступ к информации
   Организуешь всю систему так, чтобы получив доступ злоумышленнику потребовалось бы заметное время понять как именно нужно добраться до критичной информации и главное, расставляешь ловушки, сигнализирующие о том что сервер скомпроментировал, тогда ты уже со своей надежной машины переводишь монеты с горячего кошелька, останавливаешь сервис и разбираешься.
   
   Одним из примеров такой реализации является разделение на 2 сервера, один оперативный, основной, обслуживающий твой веб сервис и твоих пользователей, второй - защищенный, обслуживающий только исходящие переводы. Второй сервер значительно менее требовательный на столько, что его можно разместить чуть ли не у владельца дома или даже к примеру смартфоне (абсурд но как ни странно такая модель имеет место быть). Между серверами, по своему api идут команды, среди которых можно вставить ловушки, которые обязательно тронут злоумышленники и это даст нужный сигнал на отключение системы. В такой схеме нужно понимать концепцию read only частей базы данных, изменения которых могут приходить только со стороннего сервера, например части, отвечающие за работу операторов, обслуживающих доставку товара в интернет магазине, могут быть изменены только с их рабочих мест, реализовывать это можно разными способами, кстати блокчейн - один из них, но как пример - каждая запись снабжается цифровой подписью, и любое изменение подписывается тем кто это изменение произвел, такие записи подделать, взломав только один сервер невозможно, а сервер, отвечающий за отправку монет будет принимать только правильно подписанные записи... в общем реализация потребует творческого подхода но все реально.
   
   Само собой описанный способ не самый лучший но хотя бы доказуемо надежный, из простых способов я посоветовал бы просто хранить критичную информацию исключительно в оперативной памяти, слегка обфусцированной, защита от простого сканирования памяти, а сам процесс ее загрузки делать в момент включения сервера (или его полной установки из резервной копии, для чистоты, каждый раз когда происходит его выключение)
   
3. Гомоморфное шифрование
   Этот подход я не видел в реализации, так как невероятно сложен (если что математика уже реализована, есть библиотеки, например HElib, зато позволит проводить полностью все операции на сервере а самую последнюю, собственно отсылку - на доверенном сервере
   гомоморфные вычисления позволяют проводить математические операции над зашифрованными данными без их расшифровки, т.е. сервер, выполняющий эти операции не будет знать ответа, поэтому доверять таким вычислениям можно без оглядки (правда сервер может пропустить вычисления, но это легко решается добавлением в каждую операцию какое то вычисление, связанное с прошлой, в общем легко будет заметить что сервер перестал отвечать)