none
SQL Server Konsolidirung: Berechtigungskonzept. Neu Features in SQL Server 2012 & 2014 RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo Experts,

    ich benötige Ideen, Anregungen, Tutorials, Tipps und Links für einen Migration / Konsolidierungsszenario. Schwerpunkt: Berechtigungen.

    Gegeben ist ein breiter Landschaft an SQL Server 2008 R2 Instanzen (2 nodes Cluster, activ / activ). Historisch gewachsen sind das ca. 10 Instanzen mit vielen Datenbanken und dazugehörigen Anwendungen. Die Aufgabe wäre, diesen Landschaft auf wenige Instanzen zu konsolidieren.

    Bekannt ist dass es neue Features gibt (ab den SQL Server 2012), welche erlauben den ehemaligen (vor der Migration) sa, in einer konsolidierten Umgebung (nach der Migration) annähernd ähnliche Berechtigungen zu (automatisiert?)erteilen, allerdings ohne dass sie sa bleiben, der Funktionalität der Anwendungen(welche sich mit dem SQL Server verbinden) darf nicht beeinträchtigt werden.

    Wer weiß genaues?

    Danke und Gruß

    Irina

     


    Irina



    Mittwoch, 24. Februar 2016 08:43
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden

    Hallo Irina,

    der SQL Account "sa" hat immer SysAdmin Rechte, da musst Du nichts anpassen.

    Allerdings sollte man für Anwendung nie den "sa" oder einen anderen Account der Server Role "SysAdmin" verwenden, denn die Logins haben i.d.R. weit zuviel Rechte, als eine Applikation im Normalfall benötigt.

    Mit neuem Feature meinst Du vermutlich, das man nun auch benutzerdefinierte Server Rollen anlegen kann, um Rechte auf Serverebene einfacher delegieren zu können; siehe
    Server-Level Roles
    CREATE SERVER ROLE (Transact-SQL)

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Mittwoch, 24. Februar 2016 09:29
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Irina,

    Die Contained User sind eigentlich nur für Contained Databases gedacht. Ein Contained User hat nur Rechte auf diese eine Datenbank. Wenn es für die Anwendung ausreicht keine serverweiten Rechte zu haben dann kannst du dem Login auch einfach die sysadmin Rechte weg nehmen und auf public lassen und dann ggf. db_owner Rechte auf die Datenbank geben.

    Wenn die Anwendung tatsächlich den sa nutzt muss du auch den Login der Anwendung ändern.

    Gruß Benjamin

    Benjamin Hoch
    MCSE: Data Platform,
    MCSA: Windows Server 2012,

    Mittwoch, 24. Februar 2016 15:53
    |

Alle Antworten

  • Question
    Anmelden
    1
    Anmelden

    Hallo Irina,

    der SQL Account "sa" hat immer SysAdmin Rechte, da musst Du nichts anpassen.

    Allerdings sollte man für Anwendung nie den "sa" oder einen anderen Account der Server Role "SysAdmin" verwenden, denn die Logins haben i.d.R. weit zuviel Rechte, als eine Applikation im Normalfall benötigt.

    Mit neuem Feature meinst Du vermutlich, das man nun auch benutzerdefinierte Server Rollen anlegen kann, um Rechte auf Serverebene einfacher delegieren zu können; siehe
    Server-Level Roles
    CREATE SERVER ROLE (Transact-SQL)

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Mittwoch, 24. Februar 2016 09:29
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Olaf,

    vielen Dank.

    Wir haben die ganzen sa Berechtigungen verschiedener apps vorgefunden und mochten sie adequat ersetzen, damit sie ihre Funktionalität beibehalten und keine Server admins sind. Tatsächlich kommt mir so vor, dass benutzerdefinierte Berechtigzngen in 2008 es noch  nicht gegeben hat. 

    Gruß

    Irina

    Irina

    Mittwoch, 24. Februar 2016 11:16
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Irina,

    die Berechtigungen für Nutzer gab es quasi schon immer. Mit der Zeit sind einige Funktionen wie Schemas als Sicherheitsebene oder die angesprochenen Server Rollen hinzugekommen. Leider muss man sagen dass viele Softwarehersteller sich keine Gedanken um Berechtigungen machen und einfach immer alles unter dem SA bzw. sysadmin Kontext laufen lassen wollen.

    Gruß Benjamin

    Benjamin Hoch
    MCSE: Data Platform,
    MCSA: Windows Server 2012,

    Mittwoch, 24. Februar 2016 12:24
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Benjamin,

    in meinem konkreten Fall haben sämtliche Apps eine sa Login.

    Außer Benutzerdefinierten Serverrollen gibt es noch mit der SQL Server 2012 "Contained Users"

    Als Vorgehensweise habe ich das hier gefunden:

    http://dba.stackexchange.com/questions/25680/set-sa-to-weak-password-in-sql-server-2012

    Danke und Gruß

    Irina

    Irina

    Mittwoch, 24. Februar 2016 15:42
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Irina,

    Die Contained User sind eigentlich nur für Contained Databases gedacht. Ein Contained User hat nur Rechte auf diese eine Datenbank. Wenn es für die Anwendung ausreicht keine serverweiten Rechte zu haben dann kannst du dem Login auch einfach die sysadmin Rechte weg nehmen und auf public lassen und dann ggf. db_owner Rechte auf die Datenbank geben.

    Wenn die Anwendung tatsächlich den sa nutzt muss du auch den Login der Anwendung ändern.

    Gruß Benjamin

    Benjamin Hoch
    MCSE: Data Platform,
    MCSA: Windows Server 2012,

    Mittwoch, 24. Februar 2016 15:53
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Benjamin,

    war ja nur als mögliche alternative gedacht um Datenbanken inkl Logins nun leicht von Server zu Server zu bringen. Im praktischen Sinne hast Du natürlich Recht mit dem db_owner auf bestimmte DB.

    Gruß und Dank

    Irina

    Irina

    Mittwoch, 24. Februar 2016 16:16
    |
  • Question
    Anmelden
    1
    Anmelden

    Hallo Irina,

    das Thema "sysadmin ersetzen" wird tatsächlich seit einigen Releases verfolgt und tatsächlich gab es im SQL Server 2012 erste Möglichkeiten dazu. Leider jedoch nicht umfassend, so dass jemand mit etwas know-how leicht seine Privilegien wieder erhöhen kann.

    - in SQL Server 2014 wird zwar ein Weg verschließbar, aber eben immer noch nicht alle.

    Ich empfehle Dir diese beiden Blog-Artikel (ja, sie sind von mir) durchzugehen. Dort sollte (fast) alles dazu zu finden sein, was geht, und was eben doch nicht geht und warum:

    CONTROL SERVER gegen Sysadmin/sa: Berechtigungen, Systemprozeduren, DBCC, automatische Schema-Erstellung und Privilegienausweitung - Fallstricke

    New Permissions in SQL Server 2014: IMPERSONATE ANY LOGIN, SELECT ALL USER SECURABLES, CONNECT ANY DATABASE and the old CONTROL SERVER

    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com


    Mittwoch, 24. Februar 2016 22:33
    |