Безопасность LightSwitch

Защита доступа к приложениям LightSwitch

Валери Дж. Андерсен

Мэтт Эванс
Шил Шах
Майкл Саймонс

Продукты и технологии:

Visual Studio LightSwitch, Microsoft Azure, IIS, ASP.NET

В статье рассматриваются:

• аутентификация и авторизация;

• защита доступа в трехуровневых приложениях;

• управление доступом через отношения;

• использование средств управления доступом в IIS;

• защита приложений LightSwitch Azure.

Посмотрим правде в глаза: реализация защиты приложения зачастую является ужасающей по своей сложности задачей. К счастью, Visual Studio LightSwitch упрощает управление доступом к бизнес-приложениям на основе разрешений, позволяя создавать приложения с логикой управления доступом, отвечающей конкретных требованиям вашего бизнеса.

Приложение LightSwitch логически состоит из трех уровней: презентационного, логики и хранилища данных; вам нужно будет продумывать доступ к активам на каждом из них, чтобы обеспечить подходящие уровни доступа. С помощью LightSwitch можно встраивать логику управления доступом в приложение на нужном уровне. Более того, вы обнаружите, что LightSwitch использует базовые средства управления доступом в нижележащих технологиях и позволяет настраивать распространенные конфигурации управления доступом через IIS и ASP.NET.

В этой статье поясняется, как работает управление доступом в приложениях LightSwitch. Первым делом мы опишем средства LightSwitch, которые обеспечивают управление доступом в трехуровневой архитектуре. Затем вкратце рассмотрим развертывание, так как оно связано с управлением доступом, и покажем некоторые способы расширенного управления доступом с помощью технологий, поддерживающих LightSwitch. Наконец, мы обсудим управление доступом при развертывании в среде Microsoft Azure.

Основы управления доступом

В управлении доступом в приложениях LightSwitch есть два аспекта. Первый — аутентификация, или то, как приложение проверяет, что пользователь — именно тот, за кого себя выдает. Второй — авторизация, с помощью которой определяется, что пользователю разрешено делать или видеть в приложении.

Аутентификация

Процесс аутентификации определяет, является ли пользователь тем, кем он себя объявляет. Первый уровень управления доступом в LightSwitch требует, чтобы пользователи идентифицировали себя в приложении. К поддерживаемым режимам относятся аутентификация средствами Windows и на основе форм. Эти варианты можно сконфигурировать в свойствах приложения на вкладке Access Control, как показано на рис. 1.

Рис. 1. Определение разрешений в дизайнере приложений

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

Во втором варианте, при аутентификации на основе форм, пользователю предлагается ввести свои имя и пароль в момент открытия приложения. По умолчанию в LightSwitch эти значения проверяются по базе данных. Аутентификация на основе форме хорошо подходит для клиентов, работающих через Интернет или не входящих в Windows-домен.

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

Аутентификация дает возможность идентифицировать, кто имеет право использовать приложение, а кто — нет, и в некоторых видах приложениях этого может оказаться достаточно для соблюдения всех требований к управлению доступом. После аутентификации пользователя вы можете выбрать полное доверие к нему и разрешить доступ ко всем данным. В этом случае ваша реализация управления доступом закончена, и никаких дополнительных разрешений или кода не нужно. Вы должны лишь принять во внимание параметры IIS, обсуждаемые в разделе «Соображения по развертыванию, касающиеся управления доступом» для защиты своего приложения на сервере хостинга.

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

Авторизация

LightSwitch предоставляет систему авторизации на основе разрешений для создания бизнес-правил, как показано на рис. 2.

Рис. 2. Реализация авторизации в LightSwitc

Разрешения указываются в дизайнере приложений (рис. 1). Потом вы можете написать код, чтобы проверять, есть ли у текущего пользователя требуемые разрешения. Методы управления доступом допускается реализовать в сущностях, запросах и экранах, поэтому вы можете легко писать логику, проверяющую, имеет ли право текущий пользователь просматривать или изменять определенные данные или открывать конкретный экран.

В LightSwitch есть встроенное разрешение Security Administration, и любой пользователь, получивший это разрешение, становится администратором безопасности. Разрешение Security Administration позволяет вошедшему пользователю получать доступ к экранам Security Administration в выполняемом клиентском приложении LightSwitch, которые автоматически показываются пользователям с такой привилегией. Администратор безопасности создает роли, необходимые для приложения, и назначает каждой роли подходящие разрешения, как показано на рис. 3. Затем он создает пользователей и связывает их с нужными ролями (рис. 4).

Рис. 3. Создание ролей в период выполнения

Рис. 4. Назначение пользователей ролям в период выполнения

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

Однако вам не потребуется развертывать свое приложение для проверки правильности выдачи разрешений. При запуске приложения LightSwitch в отладочном режиме, аутентификация и система ролей выполняются в особом режиме, в котором среда разработки автоматически пытается аутентифицировать специального тестового пользователя. Вы можете выдавать или отклонять разрешения, имеющиеся у тестового пользователя, из дизайнера LightSwitch, используя столбец Granted for debug («выдано для отладки»). Затем приложение запускается в отладочном режиме с выбранными разрешениями, благодаря чему вы можете проверить написанную логику, манипулирующую разрешениями. Таким образом, вы можете быстро верифицировать точность проверок разрешений без создания  конфигурации с множеством тестовых пользователей и ролей.

Где важно контролировать доступ к ресурсам приложения

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

Первым делом следует подумать о защите данных на уровне логики. Когда разработчики управляют данными на уровне логики, презентационный уровень зачастую реагирует корректно и автоматически. Например, если у пользователя нет разрешения на удаление данных Employee, в сетке, показывающей данные Employee, кнопка удаления будет отключена. Это лишь один из примеров мощи и удобства LightSwitch в создании приложений.

Реализация управления доступом на уровне данных делает приложение более безопасным. Защита данных только на презентационном уровне оставляет ваши данные открытыми на уровне логики. Злонамеренный аутентифицированный пользователь мог бы обойти презентационный уровень и напрямую обратиться к сервису для чтения или изменения данных. Это относится не только к трехуровневой архитектуре приложений LightSwitch, но ко многим другим трехуровневым приложениям. Презентационный уровень отвечает за должное отображение данных, но не является единственным способом для аутентифицированного пользователя обратиться к данным, если на уровне логики не реализовано соответствующее управление доступом.

Защита данных на уровне логики

Уровень логики включает две основные группы компонентов, где вы применяете проверки разрешений: сущности и запросы.

Сущности Являются универсальным механизмом для доступа и работы с данными приложения. Над сущностями можно выполнять четыре основных операции: чтение, вставку, обновление и удаление. LightSwitch предоставляет разработчикам точку подключения для контроля разрешений пользователя при выполнении каждой операции и простой API для проверки того, есть ли у текущего пользователя конкретное разрешение, определенное в приложении. В следующем коде дан пример проверки разрешений и различных шлюзовых методов (gate methods), поддерживаемых API для проверки разрешений:

partial void Employee_CanUpdate(ref bool result)
{
  result = Application.Current.User.HasPermission(
    Permissions.EmployeeUpdate);
}

partial void Employee_CanInsert...
partial void Employee_CanRead...
partial void Employee_CanDelete...
partial void SaveChanges_CanExecute...

Обратите внимание на пару моментов. Во-первых, эти методы, кроме SaveChanges_CanExecute, реализованы в наборе сущностей в целом, а не в их конкретных экземплярах. Поэтому любые проверки не могут относиться к значениям в конкретном экземпляре. Метод SaveChanges_CanExecute управляет доступом к изменениям во всем источнике данных, а значит, не может содержать никакой логики, специфичной для сущности или набора сущностей. Во-вторых, если метод Employee_CanRead возвращает false, методы Employee_CanUpdate и Employee_CanDelete не вызываются, так как в этом случае они тоже вернули бы false. Пользователю не разрешают обновлять или удалять данные, если ему запрещено читать их.

Can-методы являются базовым способом обеспечения «крупнозернистой» защиты. Они поддерживают базовые политики управления доступом к данным. Однако у них есть некоторые ограничения. Если вам нужен более тонкий контроль за чтением данных, вы можете реализовать логику управления доступом в запросах. Чтобы более тонко контролировать запись данных, вы должны делать это в конвейере сохранения (save pipeline).

Запросы Также защищаются на уровне логики. У каждого запроса есть метод, позволяющий контролировать доступ. LightSwitch автоматически генерирует три запроса для каждой имеющейся сущности: запрос All для возврата всех экземпляров сущности и запросы Single и SingleOrDefault для возврата одного экземпляра сущности по ключу. Каждый из этих встроенных запросов имеет метод CanExecute, который можно использовать для реализации контроля доступа:

partial void Employees_All_CanExecute(ref bool result)
{
  result = Application.Current.User.HasPermission(
    Permissions.QueryEmployees);
}

partial void Employees_Single_CanExecute...
partial void Employees_SingleOrDefault_CanExecute...

Важно отметить, что запросы LightSwitch являются составными (composable), т. е. новые запросы можно создавать на основе существующего. Когда к запросам применяется логика управления доступом, требования разрешений в начальном запросе служат в качестве ввода для запросов, сформированных на основе этого запроса. Запросы Single и SingleOrDefault опираются на запрос All, поэтому, защищая запрос All, вы защищаете и все запросы на его основе, если в производном запросе не указываются какие-либо специфические разрешения. Однако при желании вы можете задавать в производном запросе менее ограничивающие разрешения, чем в исходном. Кроме того, метод CanRead набора сущности будет применять до CanExecute для любых запросов этого типа.

На рис. 5 показан пример композиции запроса: если запрос NorthAmericaEmployees создается в сущности Employee, он базируется на встроенном запросе Employee_All. Поэтому любая логика управления доступом, применяемая через Employee_All_CanExecute, будет также применяться к запросу NorthAmericaEmployees, поскольку этот запрос основан на запросе Employee_All (при условии, что в производном запросе не пишется какой-либо специфический код). Если доступ к запросу NorthAmericanEmployees нужно разрешить лишь определенным пользователям, можно ввести в него специфические ограничения или открывать к нему доступ через метод NorthAmericaEmployees_CanExecute, где указываются конкретные разрешения.

Рис. 5. Композиция запроса в сущности Employee

Управление доступом через отношения

При работе с запросами через отношения (relationships) важно понимать, что разрешения проверяются в сущностях как отношения, которые передаются через связанные сущности. Это еще одна причина, почему так важно должным образом определять разрешения в сущностях. Если вам нужно защитить данные от доступа для чтения через отношения, тогда метод CanRead сущности должен требовать корректный уровень разрешения. В качестве примера вновь вернемся к таблице Employee и связанным данным об оплате труда (Compensation), как показано в модели на рис. 6.

Рис. 6. Модель приложения для отдела кадров

Когда запрос проходит отношение между Employee и Compensation, разрешения на чтение сущности оцениваются, когда осуществляется этот проход, а не вызывается метод Compensation_All_CanExecute. Поэтому разрешения должны быть правильно заданы в методе CanRead сущности Compensation, чтобы при проходе отношений между сущностям поддерживался корректный уровень разрешения. Вы должны понимать, что запросы можно использовать для логического вывода данных, если сущности не защищены. Например, если у вас есть запрос, который возвращает список самых высокооплачиваемых сотрудников, как показано на рис. 7, то сущность Compensation, которой вы обращаетесь для получения данных Employee, должна быть правильно защищена, чтобы доступ к этим данным через запрос был только у пользователей с соответствующими правами.

Рис. 7. Определение запроса, который возвращает список самых высокооплачиваемых сотрудников

Настройка презентационного уровня

Защитив данные на уровне логики, нужно заняться UI на презентационном уровне. Если вы хотите, чтобы пользователь вообще не получал доступа к определенному экрану, вы можете отключить этот экран методом <ScreenName>_CanRun приложения. Когда у пользователя нет прав доступа к определенному экрану, последний просто не появляется в навигационном меню. Вы также можете ограничить команды, доступные в экране, используя метод <CommandName>_CanExecute.

В экранах и сущностях доступно несколько других методов, позволяющих скрывать, показывать и контролировать конкретные элементы управления на экране, например <EntityProperty>_IsReadOnly, <ScreenControl>.IsEnabled, <ScreenControl>.IsReadOnly и <ScreenControl>.IsVisible. Хотя эти методы предназначены не для управления доступом, они весьма полезны в настройке экранов для пользователей с конкретными правами доступа. В одних случаях лучше всего скрывать данные, которыми пользователь не может манипулировать, в других — показывать элементы управления только для чтения, а в третьих — подсказывать пользователю, как правильно вводить данные, и возвращать сообщения с внятным описанием ошибок, если таковые были допущены. Презентационный уровень LightSwitch обеспечивает необходимый уровень гибкости.

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

Защита данных на уровне хранилища

Уровень хранилища — то место, где ваша информация хранится в базе данных. Вы можете управлять доступом к уровню хранилища, требуя ввода логина, чтобы пользователь мог получить минимально необходимые привилегии в обращении к базе данных. Приложение использует этот логин при подключении к базе данных и выполнении нужных операций. Весь процесс подключения к данным осуществляется через промежуточный уровень, и конечные пользователи никогда не получают прямого доступа к данным или к строке подключения в трехуровневом приложении. Развертывая приложение LightSwitch, вы должны указывать строку подключения, которая будет использоваться для доступа к данным, как показано на рис. 8. Если уникальный логин для базы данных не существует в приложении, LightSwitch поможет администратору приложения создать такой логин. Настоятельно рекомендуется, чтобы пользователь базы данных идентифицировался как специфичный для данного приложения и получал доступ только к релевантным данным, используемым приложением.

Рис. 8. Задание строки подключения к базе данных для приложения, выполняемого при развертывании

Стоит упомянуть, что защищенное приложение LightSwitch можно развертывать как двухуровневое. При развертывании такого приложения как двухуровневого презентационный уровень и уровень логики выполняются на компьютере пользователя. Эта конфигурация дает пользователю клиента доступ к файлу web.config, где хранится строка подключения к базе данных, а значит, такая конфигурация не предлагает разделения презентационного уровня и уровня логики, что необходимо для конфигурации защищенного приложения. Зная строку подключения, пользователь может получить прямой доступ к базе данных и обойти любую логику управления доступом на промежуточном уровне. В этом случае между промежуточным уровнем и базой данных лучше всего задействовать Windows-аутентификацию. Иначе для должной защиты приложение нужно развертывать как трехуровневое.

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

При первом развертывании приложения LightSwitch вам нужно создать административного пользователя LightSwitch. Изначально это единственный пользователь с разрешениями администратора. Затем через этого пользователя вы конфигурируете роли и пользователей в клиентском приложении, как обсуждалось ранее. Заметьте, что этот пользователь будет администратором вашего приложения LightSwitch, но для этого ему не требуется быть администратором Windows. Для создания нового административного пользователя вне процесса развертывания доступна утилита командной строки. Эту утилиту, Microsoft.LightSwitch.SecurityAdmin.exe, вы найдете в каталоге установки LightSwitch.

Использование средств управления доступом в IIS

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

LightSwitch иSSL Подобно веб-браузерам и веб-серверам клиенты и серверы LightSwitch взаимодействуют по протоколу HTTP. Этот протокол определяет, что данные должны передаваться открытым текстом, а значит, любой злоумышленник в сети мог бы вести мониторинг данных, которыми обмениваются клиенты и серверы. Для защиты коммуникаций вы должны использовать протокол HTTPS, который скрывает обычные HTTP-данные в зашифрованном туннеле.

Приложения LightSwitch можно развертывать так, чтобы клиенты взаимодействовали с сервером по протоколу HTTPS. Это защищает не только конфиденциальные бизнес-данные, которыми обмениваются клиент и сервер, но и удостоверения защиты при аутентификации на основе форм. Лучше всего развертывать приложение на HTTPS-сайт, если вы решили применять аутентификацию на основе форм в сочетании с IIS или Microsoft Azure. В ином случае атакующий может украсть маркер аутентификации и подменить вошедшего пользователя. При аутентификации средствами Windows атакующий не может восстановить пароли пользователей или подменять пользователей, даже если применяется HTTP вместо HTTPS. Однако независимо от режима аутентификации бизнес-данные, передаваемые между клиентом и сервером, все равно уязвимы без использования HTTPS.

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

Чтобы веб-браузер мог доверять идентификации сервера, с которым он ранее не контактировал, сертификат сервера должен быть иметь криптографическую подпись от доверенного центра сертификации (certificate authority, CA). Вы можете приобрести сертификат у целого ряда провайдеров, в том числе verisign.com, entrust.net, instantssl.com или geocerts.com. Поскольку большинство провайдеров взимает плату за генерацию или подпись сертификатов серверов, в среде разработки обычно используется самостоятельно сгенерированный и неподписанный (а значит, и не доверяемый) сертификат.

Веб-серверы, взаимодействующие по HTTPS, полагаются на установленный сертификат сервера.

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

Однако, если вы используете настольное приложение LightSwitch, размещенное в IIS, и обращаетесь к нему по HTTPS, то у IIS-сервера должен быть доверяемый сертификат. Silverlight запрещает выполнять настольные приложения с сервера, имеющего не доверяемые сертификаты. Не доверяемый сертификат приведет к тому, что приложение, вроде бы успешно установленное, не удастся запустить. Чтобы исправить эту проблему, либо заставьте свой веб-браузер доверять этому сертификату сервера, предварительно установив его в хранилище сертификатов на клиентской стороне, либо замените сертификат сервера на подписанный одним из доверяемых CA. Заметьте, что вам понадобится один из этих корректирующих шагов перед первым обращением к приложению с данного клиента; иначе клиент сочтет, что сертификат изменился или взломан.

IIS Для хостинга приложений LightSwitch с SSL на IIS-сервере никаких конфигураций, специфических для LightSwitch, не требуется. Администраторы сервера должны сконфигурировать веб-сервер на поддержку HTTPS и выбрать сертификат, как обычно.

На самом деле возможно размещать приложение LightSwitch, использующее как HTTP, так и HTTPS, и бывают ситуации, в которых желателен именно такой вариант. Но, как уже упоминалось, следует помнить, что любой клиент, подключенный по HTTP, не защищает информацию о пароле пользователя или конфиденциальные бизнес-данные.

В последних версиях IIS по умолчанию Default Web Site прослушивает HTTP- и HTTPS-соединения одновременно. Администратор сервера может принудительно развернуть приложение LightSwitch на такой сервер, чтобы требовать подключение по HTTPS и перенаправлять любые входящие HTTP-соединения на конечную точку HTTPS. Соответствующий параметр имеется в файле web.config приложения LightSwitch.

Конфигурация пула приложения При публикации в IIS подумайте о том, чтобы выполнять приложение в собственном пуле. Пулы приложений не только обеспечивают изоляцию между рабочими процессами (worker processes) (поэтому, если одно из веб-приложений рухнет, оно никак не повлияет на остальные приложения на сервере), но и позволяют выполнять приложение под разными идентификациями. Таким образом, вы можете создать пул, где размещается веб-приложение или набор сервисов, выполняемых под специфической Windows-идентификацией, и разрешить доступ лишь к ресурсам, которые нужны этой идентификации для работы приложения. В случае приложения LightSwitch дополнительным ресурсом будет база данных. По умолчанию мастер развертывания публикует приложение в пул ASP.NET 4, выполняемый под учетной записью компьютера. Однако эта идентификация не имеет доступа к базе данных приложения, поэтому запуск приложения в таких условиях приведет к появлению сообщения об ошибке вроде «Login failed for user 'IIS APPPOOL\ASP.NET v4.0'».

Здесь у вас есть пара вариантов. Если вы используете имя пользователя/пароль SQL Server в строке подключения, приложение скорее всего готово к работе (если у этого пользователя есть соответствующий доступ к нужной базе данных). Однако, когда при подключении к базе данных желательно применять Windows-аутентификацию, необходим отдельный пул, чтобы его можно было настроить на выполнение под учетной записью пользователя Windows с наименьшими привилегиями. Этой учетной записи также нужно выдать соответствующие права доступа к базе данных приложения.

Если вы применяете Windows-аутентификацию в IIS 7, то должны знать о наличии в нем одного дополнительного конфигурационного параметра. Когда вы задействуете собственную идентификацию пользователя в качестве идентификации пула приложения, вам нужно либо использовать провайдер Windows NT LAN Manager (NTLM) (не Kerberos), либо включить поддержку аутентификации Kerberos. Другой вариант — применение вместо этого идентификации Network Service в качестве идентификации пула приложения и дополнение этой учетной записи правами доступа к базе данных..

Защита приложений LightSwitch в Azure

Все приложения LightSwitch, размещаемые в Microsoft Azure, являются общедоступными. Следовательно, эти приложения имеют уникальный набор требований к управлению доступом.

SSL-шифрование LightSwitch по умолчанию использует конечную точку HTTPS, когда приложение публикуется в Microsoft Azure. Это делается для того, чтобы обеспечить шифрование любых конфиденциальных бизнес-данных при передаче через Интернет. LightSwitch дает возможность воздать самостоятельно подписанный SSL-сертификат для приложения в момент публикации. Хотя это отличный способ для тестирования приложения в Microsoft Azure, настоятельно рекомендуется использовать лицензированный сертификат от внешнего поставщика. Так как настольные приложения не будут работать через SSL с недоверяемым сертификатом, вы можете отключить SSL-шифрование в отладочных целях, изменив значение конфигурационного параметра развертывания Microsoft.LightSwitch.RequireEncryption на false через портал Microsoft Azure после успешного развертывания приложения.

Протестировав приложение с использованием самостоятельно подписанного SSL-сертификата, вы можете обновить SSL-сертификат без повторной публикации приложения через портал Microsoft Azure. Новый SSL-сертификат можно загрузить для размещенного приложения, изменив значение SSLCertificate на «thumbprint» для более нового сертификата и вновь включив шифрование.

Аутентификация приложения Для предотвращения несанкционированного доступа к приложениям LightSwitch в Microsoft Azure рекомендуется аутентификация на основе форм. Это не потребует дополнительной конфигурации сервера после публикации приложения. Однако, если приложению нужна Windows-аутентификация, опубликованное приложение LightSwitch понадобится присоединить к домену. Для этого нужно использовать Microsoft Azure Connect. Руководство по включению Microsoft Azure Connect вы найдете по ссылке bit.ly/qx0Z6n.

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

Чтобы разрешить приложениям LightSwitch в Microsoft Azure подключаться к этой базе данных, установите в брандмауэре флажок правила «Allow other Microsoft Azure services to access this server» в true. LightSwitch также требует добавления правила брандмауэра для IP-адреса компьютера, с которого публикуется приложение. После публикации приложения рекомендуется немедленно удалять это правило. Это предотвратит доступ к базе данных с любых других компьютеров.

Заключение

LightSwitch помогает разработчикам быстро создавать бизнес-приложения и реализовать средства управления доступом. Разработчики могут без проблем ограничить доступ к своим приложениям, используя аутентификацию. При необходимости более тонкого контроля можно применять авторизацию; соответствующие средства позволяют определять разрешения и защищать активы (ресурсы) на уровнях логики и данных, обеспечивая эффективное управление правами доступа пользователей. Часто применяемые средства IIS и Microsoft Azure можно использовать для полного управления доступом. Новую информацию читайте в блоге группы LightSwitch по ссылке blogs.msdn.com/b/lightswitch.

 

ВалериДж. Андерсен (Valerie Andersen) — менеджер программ в Microsoft, работает над Visual Studio LightSwitch. Ее цель — включить в LightSwitch средства, которые позволят разработчикам быстро создавать защищенные, качественные приложения, отвечающие потребностям заказчиков.

Мэтт Эванс (Matt Evans) — тестер ПО, занимающийся LightSwitch. Хочет добиться того, чтобы приложения LightSwitch были защищенными настолько, насколько это нужно вам.

Шил Шах (Sheel Shah) — менеджер программ в Microsoft, работает над LightSwitch. В основном занимается проектированием поддержки Microsoft Azure, развертыванием и клиентскими средствами LightSwitch.

Майкл Саймонс (Michael Simons) — старший разработчик в Microsoft, работает над LightSwitch. В основном занимается разработкой средств, связанных с данными и безопасностью.

Выражаем благодарность за рецензирование статьи экспертам Дэну Лиэфону(Dan Leeaphon), Джону Риварду(John Rivard), Дэну Сифелдту(Dan Seefeldt) и Мэтту Телману (Matt Thalman).