blog.atwork.at

news and infos about microsoft, technology, cloud and more

Was Microsoft aus dem Cloudbusiness mit Azure gelernt hat #CloudFail #CloudAwesome

Tuesday, April 15, 2014 10:04 AM Martina Grom
Mit der Build in San Francisco gibt es wieder jede Menge Neuigkeiten rund um Azure zu berichten. Einen sehr interessanten Beitrag gab es von Mark Russinovich. Als Technical Fellow im Azure Team hat er dieses Mal eine ganz neue Session gehalten, die abseits von seinen Sysinternals, Malwarehunting und Case of... Vorträgen sehr authentisch gezeigt hat, welche Erfahrungen Microsoft im Dauerbetrieb einer Business Cloud Lösung gesammelt hat und worauf man als Rechenzentrumsbetreiber achten sollte. Bereits letztes Jahr hatte ich einmal die Gelegenheit einer Q&A Session von Mark zu hören, wo er über Clouderfahrungen und zukünftige Entwicklungen berichtet hat. Eine der wichtigsten Botschaften lautet: Automatisiere soviel als möglich und setze Dich nicht über diese Automatisierungen hinweg. Das klingt natürlich ein bisschen nach SkyNet, auch die Tatsache, dass alle diese Fehler, die Mark erzählt hat, vermeidbar gewesen wären. Manche davon sind evident, eines haben alle Fehler gemeinsam, die in einem Public Cloud Umfeld geschehen: sie sind schmerzhaft, fallen auf und sind zum Teil natürlich vermeidbar. Wichtige Themen rund um einen Rechenzentrumsbetrieb: Automatisiere Skaliere Teste in Produktion (!!!) Frühe Deployments, häufige Deployments In Azure werden Incidents nach Schweregrad gemessen: Severity 3: nicht dringend, keine Kundenbeeinflussung, kann später einen Einfluss haben. Severity 2: beeinträchtigt manche Kunden und manche Services. Dringend, aber noch keine Katastrophe. Severity 1: globaler Ausfall, der mehrere Services betrifft und mehrere Kunden. Severity 0: sehr großes Problem, Kunden laufen Gefahr, ihre Daten zu verlieren. In Azure gab es einmal einen Severity 0 Fall. Beispiele von aufgetretenen Fehlern: 1. Case-Sensitive Check beim Ressourcenprovider. D.h. "mobileservice" <> "MobileService", RDFE erwartet Case-sensitive. 2. Sauberes Logging Jeder Developer sollte eine saubere Fehlerprotokollierung implementieren. Fehlermeldungen wie: "Das Abonnement ist nicht für dieses Feature vorgesehen" oder "Der Servicename ist unbekannt" ist schwierig zu finden. Build with /warnaserror. Don't supress compiler warnings. 3. Exceptional Coding Catch-all oder fail fast? Bekommt jemand einen Fehler ist es ganz normal, dass derjenige es noch einmal probiert. Mit catch-all fängt man alle Fehler ab, es kann jedoch trotzdem instabil sein. Ein fail-fast führt aufgrund der wiederholten Versuche eventuell zu einer Denial of Service Attacke. Ein Tipp ist: crash wenn es sich nicht um einen Userfehler handelt, andernfalls logge einen Fehler. Log einmal pro Stunde, damit eine Fehlerlog nicht von ein und derselben Fehlermeldung angefüllt wird. 4. VM werden nicht provisioniert In diesem Fall wurden neu erzeugte VM's in Azure nicht provisioniert. Das passierte nur bei 2 aktualisierten, brandneuen Images. Der Vorgang der Provisionierung in Azure ist dabei folgender: monatlich werden OS VHD Images neu erzeugt, die Images werden in ein repository geladen und die Funktionalität wird manuell getestet. Danach werden diese VHD's vom staging Bereich in den Produktivbereich geladen. Während dieses Vorganges wurden die Images kaputt. Das Learning daraus ist: nicht nur im Staging Bereich testen, sondern auch in der Produktivumgebung, da Daten kaputt gehen können. 5. VIP swap Ein VIP Swap ist die Umstellung einer Staging Umgebung in den Produktivbetrieb. Man deployt 2 Versionen seiner Cloud Services - Produktion und Stage. RDFE verwendet dazu Storage Tables um sich die beiden Versionen zu merken. Durch einen Bug in RDFE kam es dazu, dass diese Zeilen falsch überschrieben wurden - beide Zeilen zeigten an, die Stage Version zu sein. Updates erfolgen daher immer nur scheibchenweise. 6. Löschen von Subscriptions Interne Azure subscriptions werden von Zeit zu Zeit aufgeräumt. Bei diesen Subscriptions gab es auch welche, die für Kunden in einem Preview Stage erzeugt wurden. Dazu gibt es einen Prozess, mit dem diese aufgeräumt werden. Die damals dafür verantwortliche Personen erzeugten einen Batch und haben mit diesem den dafür vorgesehenen Prozess übersteuert. Folge war, dass viele Subscriptions, auch von Kunden, gelöscht wurden. Alle Daten konnten glücklicherweise wieder hergestellt werden, da Azure Data Retention verwendet und Daten für 90 Tage weiterhin verfügbar sind. Zudem verwendet Azure, wo immer möglich Soft Delete. 7. Zertifikat Ablauf Dies ist einer der Fälle, die weitläufig bekannt wurden. Am 22. Februar 2013 kam es zu einem Zertifikatausfall, der nahezu 11,5 Stunden dauerte, bis die volle Verfügbarkeit wieder hergestellt war. SSL Verbindungen waren plötzlich nicht mehr möglich. In diesem Fall lag es nicht daran, dass Microsoft vergessen hatte, die Zertifikate zu erneuern, bereits 180 Tage vorher werden Warnungen ausgegeben, dass diese zu erneuern sind. Diese werden aktualisiert, in diesem Fall waren es drei Zertifikate, die bereits im Jänner 2013 erneuert wurden. Der Fehler hierbei war, dass vergessen wurde, diese Zertifikate mit einem Update Datum zu versehen. Dadurch passierte, dass andere Updates vorgezogen, bzw. dieses eine Update nach hinten, nach den 22. Februar verschoben wurde. Microsoft scannt nun wöchentlich alle Service Endpoints. Microsoft arbeitet hier auch an einer Vollautomatisierung. 8. Schaltjahr in Azure Zeit ist ein single point of failure. Das große Learning hieraus ist, dass Menschen Fehler machen, durch Automatisierung können diese vermieden werden. Ein Übersteuern der definierten Prozesse kann einfach schlimme Folgen haben. Tolle Session von Mark, es war eine Premiere auf der Build, hoffe, viele ergreifen die Gelegenheit und sehen sich diese Session an. Eine offene Kommunikation über gemachte Fehler und was daraus gelernt wurde, hilft uns, diese selbst in Zukunft zu vermeiden und auch mehr Vertrauen in Cloudservices zu bekommen.
Azure | Cloud | Microsoft | Security
mehr

Gedanken zur Datensicherheit

Sunday, July 7, 2013 9:05 AM Toni Pohl
Derzeit sind die Themen Datensicherheit und Prism top-aktuell in allen Medien vertreten. Es ist anzunehmen und höchst wahrscheinlich, dass wohl alle Geheimdienste und staatliche Agenturen dieser Welt hinter allen nur möglichen elektronischen Daten her sind, diese analysieren und protokollieren. Technisch gesehen ist das der” Anwendungsfall für Big Data” …
General | Security | Cloud | Impressionen
mehr

Wie Sie von Exchange Online Protection mit einem On-Premises Server zu Office 365 wechseln

Tuesday, April 2, 2013 7:29 PM Martina Grom
Exchange Online Protection ist das Antispam- und Antivirenservice von Microsoft, welches auch viele Kunden mit ihren On-Premises Exchange Servern verwenden. Das hat viele Vorteile, garantiert Exchange Online Protection (EOP, vormals FOPE, vormals EHS) ja 100% Mailvirenschutz und 98% Spamschutz. Lange Jahre begleitet mich dieses Produkt nun schon und egal wie es gerade heißt, es ist einfach immer noch sehr sehr gut. Wenn man jedoch seinen eigenen Mailserver (endlich) aufgibt und zu Office 365 wechselt, sind hierbei ein paar Schritte zu beachten. Zunächst einmal würde ich vorbereitend die TTL des MX Records bereits eine Woche vor dem Wechsel auf 5 Minuten stellen (oder 1 Minute). Den eigentlichen Umstellungszeitpunkt wähle ich dann immer entweder gegen Wochenende oder Abends oder an einem Feiertag, damit sicher gestellt ist, dass hier wenig Mailtraffic erfolgt. Dann im FOPE Administration Center anmelden und im Menüpunkt Verwaltung / Domänen die Domain deaktivieren die in Zukunft über Office 365 verwaltet wird. Danach wechseln Sie zum Punkt deaktivierte Domänen und löschen die Domain komplett aus FOPE . Ich warte dann immer rund 30 Minuten um sicher zu gehen, dass die Änderungen überall durchgeführt werden. (Keine Sorge, in dieser kurzen Zeit gehen Mails nicht sofort als unzustellbar zurück). Wenn Sie jetzt erst Ihr Office 365 Account eröffnen, können Sie in diesen 30 Minuten das Office 365 Abo kaufen und die Domain hinzufügen, validieren und die MX-Records ändern. Sobald diese validiert werden, haben Sie Office 365 und EOP im Einsatz! Wichtig: FOPE wird ab April 2013 in EOP integriert, bzw. die Services werden ab April konsolidiert. Für Administratoren bedeutet das, dass die Verwaltung einfacher wird, da damit auch EOP über https://portal.microsoftonline.com verwaltet werden kann. Für Kunden, die bereits Office 365 verwenden erfolgt die Umstellung im Rahmen der Transition zu Office 365 W15. Bei Kunden mit einem On-Premises Mailsystem erfolgt die Transition ab dem 3. Quartal 2013. Die FOPE Einstellungen werden automatisch in EOP auf Office 365 umgestellt. Alle Kunden erhalten mindestens 30 Tage vorher eine Info bezüglich der Transition.
Office365 | Microsoft | Security | Cloud
mehr

Der WebReady Document Viewing-Dienst wurde vom Administrator für Ihre Organisation deaktiviert in Office 365 und Exchange Online

Thursday, November 29, 2012 6:12 PM Martina Grom
In Exchange Online gibt es die Möglichkeit, Microsoft Office Dateianlagen (docx, pptx, xlsx, etc.) direkt innerhalb der Outlook Web App Applikation anzusehen. Diese Möglichkeit wird durch die Web Access Components bereit gestellt, die ebenfalls durch die Office Web Apps genutzt werden. Um PDF Dateianlagen direkt aus der Outlook Web App anzusehen, wird WebReady Document Viewing verwendet. Dieses Feature wurde von Microsoft Ende August 2012 in den Online Services aus Sicherheitsgründen deaktiviert, da Microsoft Online Services Operations eine Sicherheitslücke in einer 3rd Party Komponente festgestellt hat. Amir Haque (Sr. Program Manager, Product Quality) hat dies in einem Community Beitrag mitgeteilt. Was bedeutet das für die Benutzer von Outlook Web App? Wenn Sie ein PDF-Attachment direkt im Browser ansehen möchten, sehen Sie folgende Fehlermeldung: "Der WebReady Document Viewing-Dienst wurde vom Administrator für Ihre Organisation deaktiviert." An einem Patch wird gearbeitet und das Feature wird wieder frei gegeben, sobald dieser ausgerollt ist. Für jene mit einem On-Premise Exchange Server: hier finden Sie die Konfiguration von WebReady Document Viewing.
Cloud | Office365 | Security
mehr

Defense Against the Dark Ages: Your Old Web Apps Are Trying to Kill You #TEE12

Saturday, June 30, 2012 3:15 AM Toni Pohl
Auf TechEd Europe 2012 hielt Aaron Margosis von Microsoft eine Session mit diesem reißerischen Titel. Dabei geht es vor allem darum, alte Applikationen (Legacy Apps) sicher zu machen und sicher zu betreiben. Hier wurden nicht die üblichen Top-sicherheitslösche wie Cross Site Scripting und SQL Injection & Co betrachtet, sondern Sicherheits-Themen, die weniger bekannt sind.
General | Event | Microsoft | Developer | Security
mehr

Microsoft kündigt Fix für ASP.NET #hashDoS an-Azure wird automatisch gefixt

Thursday, December 29, 2011 3:00 PM Toni Pohl
Wie gestern in "Workaround gegen Denial of Service Attacke in ASP.NET #hashDoS #28C3" gewarnt, besteht bei Webservern (Windows Servern mit IIS) eine Verwundbarkeit gegen "hash collision attacks" #hashDoS. Angreifer können mit speziell präparierten HTTP-Requests eine Hash-Tabelle mit einer großen Zahl von Werten befüllen, deren Keys in demselben Hash-Code aufgelöst werden - damit sinkt die Performance der HashTable auf eine simple Linked List. Das kann bei repetitiven Requests zu einer Überlastung des Webservers führen, sinngemäß so: Betroffen ist auch ASP.NET. Microsoft arbeitet bereits an einem Fix, so schreibt ScottGu in seinem Blog: Ab heute, 29. Dezember, etwa 19h (unsere Zeitzone) wird ein Fix verfügbar sein! ASP.NET Security Update Shipping Thursday, Dec 29th ..."We are releasing the security update via Windows Update and the Windows Server Update Service.  You can also manually download and install it via the Microsoft Download Center. We will release the update on Thursday, December 29th at approximately 10am Pacific Time (US and Canada). We are announcing it ahead of time to ensure that administrators know that the security update is coming, and are prepared to apply it once it is available." Der Fix wird per Windows Update, Windows Server Update Service und im Microsoft Download Center verfügbar sein. Gestern bekannt gegeben - heute gefixt. Wow, das nenn ich wirklich rasch! Achja, betrifft die #hashDoS Verwundbarkeit Windows Azure Kunden? Nein, ScottGu schreibt: "Customers on Azure that have their Hosted Services OS servicing policy set to "Auto" (which is the default) will have their environments automatically updated to include the security update. There is no action required for this." Sehr praktisch, diese Cloud Services... Alle IT-Pros mit eigenen Webservern: Bei Verfügbarkeit Fix einspielen!!
General | Azure | Developer | Security | Windows | Cloud
mehr