none
Access 2010 SandBoxMode Operationen - lieber gleich in SQL?

    Frage

  • Servus liebe Entwicklergemeinde - und noch ein Frohes Neues :-)

    Obwohl ich mal so gar nicht aus der Entwickler Ecke komme, beschäftigt mich aktuell in einem Projekt folgende Frage:

    Office Entwickler haben extrem komplexe Access DBs gebaut, mit allerlei Code und Access Operationen. 

    Die "Apps" laufen alle und jeder scheint zufrieden - so weit, so nicht ganz so gut.

    Das Unternehmen möchte nun im Zuge des Wechsels von Office 2003 auf 2010 auch den Default SandBoxMode auf 3 stehen lassen - aus Sicherheitsgründen. 

    Nun ist es aber so, dass die selbstgebauten "Apps" eine Menge von Operationen nutzen, die im SandBoxMode 3 nicht mehr funktionieren, bzw. geblockt werden.

    Siehe hierzu auch: http://support.microsoft.com/kb/294698/de 

    Rein technisch soll es laut Aussage der Entwickler wohl theoretisch möglich sein, die blockierten Operationen durch andere Programmierungen zu ersetzen, wohl aber nur mit einem riesigen Aufwand.

    Ich bin ja nun selbst kein Entwickler und glaube das auch erstmal. 

    Meine Frage aber nun ist - wenn ich in Access eine derart Komplexe Anwendung baue .. ist Access dann noch die richtige Wahl? Wäre ich mit SQL Server nicht besser beraten? So rein aus verschiedenen Perspektiven heraus, interessiert mich mal: wann sollte ich SQL Server nehmen ... wann "darf" es noch Access sein? 

    Kann ich denn von einem Access Entwickler SQL Kenntnisse erwarten? Ist das Neu-/Umprogrammieren so aufwändig, dass ich lieber den bequemen Weg nehme und ein Sicherheitsfeature auslasse?

    Wie ist denn so die allgemeine Meinung dazu ... wer kann mir hier mal etwas Licht ins Dunkle bringen?

    Beste Grüße,

    Nicki

    Montag, 7. Januar 2013 12:58

Antworten

  • Hallo Nicki
     "Nicki Wruck" schrieb im Newsbeitrag news:70275019-3d34-4fb3-8b66-7a47dee75521@communitybridge.codeplex.com...

    Office Entwickler haben extrem komplexe Access DBs gebaut, mit allerlei
    Code und Access Operationen.
    Die "Apps" laufen alle und jeder scheint zufrieden - so weit, so nicht
    ganz so gut.
    Das Unternehmen möchte nun im Zuge des Wechsels von Office 2003 auf
    2010 auch den Default SandBoxMode auf 3 stehen lassen - aus
    Sicherheitsgründen.
    Rein technisch soll es laut Aussage der Entwickler wohl theoretisch
    möglich sein, die blockierten Operationen durch andere Programmierungen
    zu ersetzen, wohl aber nur mit einem riesigen Aufwand.

    Diese Aussage ist falsch. Wenn du z.B. OLE Automatisierung mit Word machen willst, also von Access heraus Word automatisiert starten willst, geht das im SBM 3 nicht und kann auch nicht umgangen werden. Des weiteren gibt es viele Dinge, die nicht umgehbar sind, sonst würde der Sandbox Mode ja keinen Sinn machen. Das Gute an Access ist ja gerade, dass es voll in die Office Anwendungen integriert ist und mit diesen Anwendungen optimal zusammenspielt. Mit SBM 3 wird dies wirklungsvoll unterbunden. Wolt Ihr das wirklich?!? Mit Sicherheit hat das ja dann nicht viel zu tun. Die Berechtigung der Benutzer im Betriebssystem einzuschränken ist viel effektiver und sichert zuverlässig, dass nichts gemacht wird, was der Benutzer nicht machen darf.

    Meine Frage aber nun ist - wenn ich in Access eine derart Komplexe
    Anwendung baue .. ist Access dann noch die richtige Wahl? Wäre ich mit
    SQL Server nicht besser beraten? So rein aus verschiedenen Perspektiven

    Wenn die Funktionen in Access aus sicherheitsgründen blockiert sind, wird es nichts bringen, eine SQL Server Backend zu verwenden. Es geht hier um Jet und auch wenn der SQL Server als BE verwendet wird, ist es trotzdem Jet und der Expression Service, sowie VBA, welche hier die Verarbeitung durchführen, der SQL Server (mit ausnahme von SPs und Functions) wird dann nur die Daten liefern. Damit kannst Du die Funktionen, die vom SBM 3 blokiert sind, ebenfalls nicht umgehen. Der SQL Server wird für Dich z.B. keine OLE Automatisierung mit Word ermöglichen.

    Wenn Du den SBM 3 zwingend nicht deaktivieren kannst, dann musst Du ohne Jet arbeiten. In diesem Fall heisst es dann z.B. die Antwendung komplett neu schreiben und dabei dann z.B. das DotNet Framework und WPF einsetzen und komplett auf Access zu verzichten. Der Aufwand, die gleiche Anwendung in .Net zu schreiben dürfte (nich meiner Erfahrung) etwa 2-10 mal den Aufwand ausmachen, den Ihr für das Neuschreiben der Anwendung in Access brauchen würdet. Zudem müsstet Ihr dann komplett neues Know-How aufbauen und .Net Anwendungsprogrammierer sind wesentlich "teurer", als Access Programmierer.

    Kommt hinzu: Damit wird ja dann nichts sicherer. Die in Access/Jet/VBA blockierten Ausdrücke müssen ja dann in .NET trotzdem realisiert werden und macht dann eben einfach eine andere Anwendung etwas Unsicheres.

    Das korrekte Verfahren ist SBM auf 2 zu setzen (oder gleich überhaupt nicht zu setzen) und generell zu unterbinden, dass Code in Office Dokumenten aufgeführt wird, wenn diese Dokumente nicht signiert oder als vertrauenswürdig definiert wurden. Damit haben böswillige "Dokumente" keine Chance böswilligen Code laufen zu lassen, auch wenn dieser im SBM2 erlaubt wäre. Die "Dokumente" werden dann gar nicht ausgeführt. Um nun auch noch die "bösen" Ausdrücke zu unterbinden kann man diese über VBA realisieren, also auf Ausdrücke komplett verzichten und statt dessen User Defined Functions zu verwenden. Bedingt dann zusätzlich ein Audit der als vertrauenswürdig zu bezeichnenden Anwendungen, um auszuschliessen, dass Expressions z.B. in Formularfeldern eingestreut werden können.

    Fazit: SBM 3 macht keinen Sinn. Der Wechsel auf eine andere Programmierumgebung löst das Problem ebenfalls nicht. Eine restritkive Handhabung, welcher Code ausgeführt werden darf, indem dieser signiert oder als vertrauenswürdig festgelegt wird, ist der bessere Ansatz, spart viel Geld und Investitionen und ist zudem sicherer.

    Gruss
    Henry

    Dienstag, 8. Januar 2013 04:47

Alle Antworten

  • Im Grunde brauchst du signierte Anwendungen, welche auf TrustedLocation-Laufwerken liegen.

    Montag, 7. Januar 2013 13:31
    Moderator
  • Servus Stefan,

    vielen Dank für deine Antwort. Leider führt das Signieren nicht zu dem gewünschten Erfolg. Wir haben den Test schon gemacht, mit signiert und vertrauenswürdiger Speicherort. 

    Die Operationen, die geblockt werden, funktionieren in der Tat nur mit mind. SandBoxMode 2 ... :-(

    Gruß,

    Nicki

    Montag, 7. Januar 2013 13:35
  • Am 07.01.2013 schrieb Nicki Wruck:

    Die Operationen, die geblockt werden, funktionieren in der Tat nur mit mind. SandBoxMode 2 ... :-(

    Und welche Operationen sind das? Kannst Du Beispiel-Code posten?

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Montag, 7. Januar 2013 17:35
  • Am 07.01.2013 schrieb Nicki Wruck:

    Meine Frage aber nun ist - wenn ich in Access eine derart Komplexe Anwendung baue .. ist Access dann noch die richtige Wahl? Wäre ich mit SQL Server nicht besser beraten? So rein aus verschiedenen Perspektiven heraus, interessiert mich mal: wann sollte ich SQL Server nehmen ... wann "darf" es noch Access sein? 

    Kommt auf die Anforderung an. Den SQL-Server setzt man ja nur für die
    Datenhaltung ein, eingegeben werden müssen die Daten ja auch, und da
    bietet sich eben auch Access als Frontend an.

    Kann ich denn von einem Access Entwickler SQL Kenntnisse erwarten?

    Ja. Aber nicht jeder Access Entwickler kann Stored Procedures im SQL
    Server schreiben.

    Ist das Neu-/Umprogrammieren so aufwändig, dass ich lieber den
    bequemen Weg nehme und ein Sicherheitsfeature auslasse?

    Kommt drauf an. Wenn das Backend sehr groß ist, kann das schon sehr
    aufwändig sein, es auf den SQL-Server zu portieren.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Montag, 7. Januar 2013 17:39
  • Hallo Nicki
     "Nicki Wruck" schrieb im Newsbeitrag news:70275019-3d34-4fb3-8b66-7a47dee75521@communitybridge.codeplex.com...

    Office Entwickler haben extrem komplexe Access DBs gebaut, mit allerlei
    Code und Access Operationen.
    Die "Apps" laufen alle und jeder scheint zufrieden - so weit, so nicht
    ganz so gut.
    Das Unternehmen möchte nun im Zuge des Wechsels von Office 2003 auf
    2010 auch den Default SandBoxMode auf 3 stehen lassen - aus
    Sicherheitsgründen.
    Rein technisch soll es laut Aussage der Entwickler wohl theoretisch
    möglich sein, die blockierten Operationen durch andere Programmierungen
    zu ersetzen, wohl aber nur mit einem riesigen Aufwand.

    Diese Aussage ist falsch. Wenn du z.B. OLE Automatisierung mit Word machen willst, also von Access heraus Word automatisiert starten willst, geht das im SBM 3 nicht und kann auch nicht umgangen werden. Des weiteren gibt es viele Dinge, die nicht umgehbar sind, sonst würde der Sandbox Mode ja keinen Sinn machen. Das Gute an Access ist ja gerade, dass es voll in die Office Anwendungen integriert ist und mit diesen Anwendungen optimal zusammenspielt. Mit SBM 3 wird dies wirklungsvoll unterbunden. Wolt Ihr das wirklich?!? Mit Sicherheit hat das ja dann nicht viel zu tun. Die Berechtigung der Benutzer im Betriebssystem einzuschränken ist viel effektiver und sichert zuverlässig, dass nichts gemacht wird, was der Benutzer nicht machen darf.

    Meine Frage aber nun ist - wenn ich in Access eine derart Komplexe
    Anwendung baue .. ist Access dann noch die richtige Wahl? Wäre ich mit
    SQL Server nicht besser beraten? So rein aus verschiedenen Perspektiven

    Wenn die Funktionen in Access aus sicherheitsgründen blockiert sind, wird es nichts bringen, eine SQL Server Backend zu verwenden. Es geht hier um Jet und auch wenn der SQL Server als BE verwendet wird, ist es trotzdem Jet und der Expression Service, sowie VBA, welche hier die Verarbeitung durchführen, der SQL Server (mit ausnahme von SPs und Functions) wird dann nur die Daten liefern. Damit kannst Du die Funktionen, die vom SBM 3 blokiert sind, ebenfalls nicht umgehen. Der SQL Server wird für Dich z.B. keine OLE Automatisierung mit Word ermöglichen.

    Wenn Du den SBM 3 zwingend nicht deaktivieren kannst, dann musst Du ohne Jet arbeiten. In diesem Fall heisst es dann z.B. die Antwendung komplett neu schreiben und dabei dann z.B. das DotNet Framework und WPF einsetzen und komplett auf Access zu verzichten. Der Aufwand, die gleiche Anwendung in .Net zu schreiben dürfte (nich meiner Erfahrung) etwa 2-10 mal den Aufwand ausmachen, den Ihr für das Neuschreiben der Anwendung in Access brauchen würdet. Zudem müsstet Ihr dann komplett neues Know-How aufbauen und .Net Anwendungsprogrammierer sind wesentlich "teurer", als Access Programmierer.

    Kommt hinzu: Damit wird ja dann nichts sicherer. Die in Access/Jet/VBA blockierten Ausdrücke müssen ja dann in .NET trotzdem realisiert werden und macht dann eben einfach eine andere Anwendung etwas Unsicheres.

    Das korrekte Verfahren ist SBM auf 2 zu setzen (oder gleich überhaupt nicht zu setzen) und generell zu unterbinden, dass Code in Office Dokumenten aufgeführt wird, wenn diese Dokumente nicht signiert oder als vertrauenswürdig definiert wurden. Damit haben böswillige "Dokumente" keine Chance böswilligen Code laufen zu lassen, auch wenn dieser im SBM2 erlaubt wäre. Die "Dokumente" werden dann gar nicht ausgeführt. Um nun auch noch die "bösen" Ausdrücke zu unterbinden kann man diese über VBA realisieren, also auf Ausdrücke komplett verzichten und statt dessen User Defined Functions zu verwenden. Bedingt dann zusätzlich ein Audit der als vertrauenswürdig zu bezeichnenden Anwendungen, um auszuschliessen, dass Expressions z.B. in Formularfeldern eingestreut werden können.

    Fazit: SBM 3 macht keinen Sinn. Der Wechsel auf eine andere Programmierumgebung löst das Problem ebenfalls nicht. Eine restritkive Handhabung, welcher Code ausgeführt werden darf, indem dieser signiert oder als vertrauenswürdig festgelegt wird, ist der bessere Ansatz, spart viel Geld und Investitionen und ist zudem sicherer.

    Gruss
    Henry

    Dienstag, 8. Januar 2013 04:47
  • Servus Henry,

    vielen Dank für deine sehr ausführliche Antwort. Das waren genau die Argumente, die mir weitergeholfen haben. 

    Wir werden dann SBM 2 empfehlen, CodeSignatur und die Systemberechtigungen prüfen ... dann sollte alles relevante erschlagen sein :-)

    Danke auch an Winfried für die Kommentare. 

    Beste Grüße,

    Nicki

    Dienstag, 8. Januar 2013 12:54