Удостоверяването е критичен компонент на всяка стратегия за сигурност. Днес ще обсъдим удостоверяването на SQL Server и това как е от съществено значение за защитата на вашата среда на SQL Server и ролята, която играе удостоверяването на Windows.
Установяване на връзка
Всичко започва с връзка. За да установят успешна връзка с базата данни, клиентът или приложението изисква следната информация:
- Пълно квалифицирано име на домейн на SQL Server
- Име на екземпляра
- Номер на порт
- Идентификационни данни (потребителско име и парола) за удостоверяване
Например, да предположим, че използвате онлайн банкиране. За да получите достъп до вашия акаунт, от вас се изисква да въведете идентификационни данни за целите на удостоверяване. Банката ви идентифицира, когато предоставите валидни идентификационни данни и разрешава достъп до услугите си при проверка.
По същия начин, когато влизат в SQL Server, потребителите трябва да посочат валидни идентификационни данни, така че SQL Server да може да удостовери тяхната самоличност и да предостави подходящия достъп.
SQL Server предоставя два режима на удостоверяване на сървъра:
- Удостоверяване на Windows
- Режим на удостоверяване на SQL сървър и Windows (смесен режим)
Можете да дефинирате тези методи за удостоверяване по време на инсталирането на SQL Server или да ги промените по-късно чрез рестартиране. От решаващо значение е администраторите на бази данни да разберат разликите между тези методи за удостоверяване и да ги приложат според специфичните изисквания на тяхната организация.
Нека се потопим по-нататък, за да разберем предимствата и недостатъците както на удостоверяването на SQL Server, така и на Windows.
Общ преглед на удостоверяването на SQL Server
Администраторите на бази данни създават SQL данни за влизане и предоставят подходящи разрешения за потребителите да се удостоверяват в SQL Server. Потребителите трябва да посочат потребителското име и паролата, докато се свързват със SQL Server, както е показано по-долу.
Удостоверенията на потребителя се потвърждават чрез информацията, съхранявана в главната база данни. Можете да наложите следните правила за влизане в SQL Server.
- Прилагане на правилата за пароли :Администраторите могат да проверят тази опция, за да внедрят политиката за пароли за Windows за влизания в SQL Server. Включва определяне на дължината и сложността на паролата.
- Принудително изтичане на паролата :Можете да наложите максималната възраст на паролата. Паролата ще бъде изтекла и трябва да се промени, както е определено от критериите за възраст.
- Потребителят трябва да промени паролата при следващо влизане :Администраторът задава парола по време на създаване на SQL вход. След като потребителят влезе с идентификационните си данни, той трябва да посочи нова парола и администраторите няма да знаят за тази нова парола.
Забележка:Всички тези конфигурации са на индивидуално ниво за влизане в SQL. Следователно, ако трябва да създадете множество SQL данни за влизане, трябва да конфигурирате всеки акаунт с необходимата политика.
Не можем да активираме само SQL удостоверяване. За да го активирате, използвайте опцията за смесено удостоверяване, която включва както Windows, така и SQL удостоверяване.
Недостатъци на удостоверяването на SQL Server
Има доста ограничения и недостатъци при използването само на удостоверяване на SQL Server.
- Потребителите трябва да запомнят идентификационните данни за вход в SQL и да ги предоставят в низа за връзка всеки път, когато се свързват със SQL Server. Ако имате няколко SQL сървъра, може да е трудно за потребителя да следи паролите за всеки екземпляр.
- SQL Server съхранява паролата в главната база данни в криптирана (хеш) форма. Хакерите могат да откраднат информацията чрез достъп до базата данни. Тъй като тези криптирани идентификационни данни трябва да се предават по мрежата, това може да увеличи шансовете потребителски идентификационни данни да бъдат откраднати.
- Не можете да внедрите допълнителни (персонализирани) правила за акаунти с входовете за удостоверяване на SQL Server.
- Това увеличава задачата за управление на влизане за администраторите на база данни. Администраторите на бази данни нямат централна конзола за управление за управление на влизания във всички екземпляри.
Да предположим, че имате 500+ SQL екземпляра и потребител изисква достъп до всички тези екземпляри. В този случай би било досадна задача за администратора на базата данни да се свърже с всеки екземпляр и да създаде потребителски входове. По същия начин, ако човек е напуснал организацията, администраторът на базата данни трябва да разбере SQL входовете на този индивид и да ги премахне от всички тези случаи. Това може да отнеме много време.
- При преместване на база данни в различни екземпляри може да получите проблеми с потребители-сираци и това може да се случи поради несъответствие на SID в главната и потребителската база данни в новия екземпляр.
- Трябва да управлявате политиките за сигурност за всяко влизане в SQL. Не можете да дефинирате универсална политика за всички акаунти във вашата организация. За голяма база данни е трудна задача да се дефинират правилата за всяко индивидуално влизане.
Най-добри случаи на използване за удостоверяване на SQL Server
- Може да помогне на по-стари приложения и софтуер на трети страни да свържат бази данни, ако не поддържат удостоверяване на Windows (AD).
- Може да изискате потребителите от ненадеждни домейни да се свържат със SQL Server. В този случай приложението може да посочи SQL данни за влизане в низовете за връзка и да се свърже с базата данни.
- За свързване на самостоятелни SQL екземпляри, които не са част от групите на Active Directory (AD).
- Може да помогне на SQL Server да поддържа уеб приложения, където потребителите създават свои собствени самоличности.
- Администраторите споделят общ идентификатор за свързване със SQL Server чрез удостоверяване на Active Directory в няколко случая. Това обединяване на връзки не е добра практика. В този случай можете да създадете отделни данни за вход за всеки потребител и да се свържете с базата данни, като използвате неговите идентификационни данни.
- По подразбиране, ако внедрите SQL база данни в облака, т.е. Azure SQL база данни или AWS RDS, ви се предоставят идентификационни данни за вход за удостоверяване на SQL Server. По-късно, ако е необходимо, можете да конфигурирате удостоверяване, базирано на AD.
- Можете да го използвате за свързване от различни операционни системи като Linux и macOS.
Общ преглед на удостоверяването на Windows
При удостоверяване на Windows потребителят трябва първо да се удостовери в Active Directory. SQL Server удостоверява потребителите чрез главния маркер на Windows в операционната система. С това SQL Server не иска парола за проверка на самоличността. Следователно Windows потвърждава самоличността на потребителите за удостоверяване. SQL Server не съхранява идентификационните данни в удостоверяването на Windows. Връзката, използваща удостоверяване на Windows, се нарича доверена или интегрирана връзка.
Забележка:Удостоверяването на Windows е методът за удостоверяване по подразбиране, когато инсталирате SQL Server.
Предимства на удостоверяването на Windows
- Удостоверяването на Windows е сигурен начин за свързване със SQL Server и използва токените и SPN за целите на удостоверяване с помощта на протокола за удостоверяване на Kerberos. Следователно той не изпраща пароли в мрежата и предпазва от кражба на пароли в мрежата.
- SQL Server не съхранява идентификационните данни на потребителя.
- Той използва протокол за сигурност Kerberos и можете да прилагате политики за пароли, като сложни пароли, блокиране на акаунти и изтичане на паролата. Тази политика за пароли може да бъде приложена на ниво организация на всички сървъри. Следователно можете да контролирате политиките за сигурност на потребителите на ниво организация, вместо на ниво индивидуално влизане, както при удостоверяването на SQL Server.
- Удостоверяването на Windows позволява разделянето на задълженията. Екипът на Active Directory (AD) управлява потребителите на AD. Докато DBA добавя AD потребители в SQL екземпляри и предоставя подходящи разрешения.
- Active Directory помага за създаване на групи в Windows. Екипът на AD може да добави няколко души, които изискват равен достъп в AD група. По-късно можете да добавите групата в SQL екземпляр и да предоставите разрешения на ниво група. Следователно, ако се присъедини нов човек, след като е част от AD групата, достъпът до база данни се предоставя автоматично в сървъра, където съществува тази AD група. По същия начин, след като потребител се премести от организацията и неговият идентификатор бъде премахнат от тези рекламни групи, той вече няма да има достъп до базата данни.
Недостатъци на удостоверяването на Windows
- Ако използвате само удостоверяване на Windows за SQL Server, всички потребители трябва да са част от Active Directory.
- DBA нямат контрол върху AD входовете и групите.
- Членството в AD групата не е известно на DBA. Не получавате известие, ако потребител бъде добавен или премахнат от рекламните групи.
Резюме
Тази публикация в блога очертава ключовите компоненти на удостоверяването на SQL Server и удостоверяването на Windows. Надявам се, че ви помага да разберете разликите между тези методи за удостоверяване, за да решите кой е най-подходящ за вашия бизнес и обстоятелства.
Удостоверяването на SQL Server може да се използва на същата машина като SQL Server или на отдалечена връзка. Ако работите в среда на Active Directory, се препоръчва да използвате удостоверяване на Windows. Ако работите в среда без Active Directory, можете да използвате удостоверяване на SQL Server за връзки към базата данни.
Удостоверяването на Windows осигурява повече сигурност и гъвкавост за управление на влизания в SQL Server. Следователно, трябва да го използвате, когато е възможно.
