Как защитить ASP.NET MVC приложение от администратора?

Question

[Валерий Абакумов]

Добрый день, уважаемые коллеги!

Есть корпоративное (можно сказать, "интранет") ASP.NET MVC приложение. Данные хранятся в локальной БД на Firebird. Это приложение поставляется "в массы". Есть системные администраторы, которые разворачивают это приложение на своих серверах (т.е. развертывание выполняется нецентрализованно). В MVC-приложении вся логика, как известно, находится в *.dll. Но Views открыта для просмотра и редактирования, и при желании, какой-нибудь "ушлый" администратор может либо поломать что-либо во View, либо написать какой-нибудь JS-код (или изменить существующий), который будет работать "в обход" основной логики приложения (изменить поведение каких-либо кнопок, например).

Вопрос следующий: каким образом можно защитить всё приложение таким образом, чтобы "ушлые" пользователи не могли изменить логику работы приложения или его составных частей (Views, JS-кода)?

Возможные варианты:

1. можно обфусцировать всё, что можно, но как тогда это сделать так, чтобы и Views рендерились нормально, и JS-код успешно выполнялся?
   
2. можно шифровать всё содержимое Views и JS-кода, но ключ где тогда хранить? (ключ, впринципе, можно хранить и в локальной БД - особо страшного тут ничего не будет, т.к. логика по шифрованию/дешифрованию будет "зашита" в *.dll, которые, насколько я понимаю, достаточно трудно декомпилировать - или я ошибаюсь?)
   

Примечание: в локальной БД на Firebird данные хранятся в открытом виде, и по сути, ничего не мешает их оттуда считывать. В принципе, это не особо страшно, что эти данные могут увидеть сисадмины - главное, чтобы нельзя было "прочитать" и изменить логику работы и поведения всего приложения.

Comments

[Станислав Макаров]

> будет "зашита" в *.dll, которые, насколько я понимаю, достаточно трудно декомпилировать
dotPeek пользовались когда-нибудь? Если нет, найдите время глянуть, он бесплатный)

[Валерий Абакумов]

Станислав Макаров спасибо, да, глянул :) похоже, что тут спасет только обфускация - чтобы при просмотре *.dll в dotPeek было ничего не понятно или хотя бы мало что понятно

Answer 1

[Валерий Абакумов]

Коллеги, в принципе, можно отнести это к решению вопроса - в Visual Studio при публикации ASP.NET приложения в настройках Publish'а есть такая опция - "Precompile during publish". При конфигурировании этой опции снимается галочка с "Allow precompiled site to be updatable" + можно поиграться с блоком "Merge option". Эта галочка способствует тому, что все View при публикации будут преобразованы в *.dll файлы, а блок "Merge option", насколько я понял, позволяет настроить различные способы этого преобразования View -> dll. Решение пока отмечать не буду - хотелось бы услышать еще варианты и "поиграться" с этими настройками публикации.

Answer 2

[Макс]

ИМХО пока и данные и приложение находятся у пользователя - никак.
только забрать данные и бизнесс-логику в контроллируемое пространство, пользователю отдать только интерфейс

Answer 3

[Fredcapit]

А может сервер всё-таки иметь один? Зачем куча экземпляров?

Comments

[Валерий Абакумов]

Fredcapit специфика предметной области этого проекта требует наличия децентрализованных серверов (т.е. есть некие точки, где есть сервер и несколько клиентов. На этих точках интернет где-то есть, где-то нет, поэтому выносить приложение на более централизованный уровень невозможно. Остается только уровень этих точек. А в этих точках могут сидеть "ушлые" пользователи. Поэтому и встал данный вопрос :) ).

[Dmitry Pavlov]

Валерий Абакумов: пользователи ведь не анонимно работают? добавьте устрашающее сообщение на UI, что любые попытки что-либо менять - повлекут за собой страшную и неотвратиму кару :) Муляж систем видеонаблюдения в магазинах защищает не хуже реально системы безопасности :)

[Валерий Абакумов]

Dmitry Pavlov мне понравился ход Ваших мыслей :)

Answer 4

[Дмитрий Ковальский]

Можно анально огородить Базу. Доступ только до уровня хранимок, гранты на хранимки выдаются только вами при инициации базы.

Answer 5

[Dmitry Pavlov]

Всю логику с клиента убрать - пусть будут старые добрые постбеки. Все делать на сервере, усиленную валидацию в том числе. Серверные сборки обфусцировать при билде. Если совсем хочется хардкорно и UI не слишком сложный - можно его рендерить тоже на сервере.

Однако физический доступ к защищаемому обхекту - это по определению нарушение защиты. Вопрос с централизованным защищенным от доступа посторонних сервером, можно рещить и в интранете.