Jump to content

NilsK

Expert Member
  • Gesamte Inhalte

    17.511
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von NilsK

  1. Moin, Berechnungen innerhalb eines Feldes gibt es nicht. Das macht man üblicherweise in einer Abfrage oder einer View. Man kann das zwar auch per Trigger lösen, aber das ist nach der reinen RDBMS-Lehre nicht zulässig, weil es zu denormalisierten Daten führt (die Daten der Spalte ergeben sich ja direkt aus bereits vorhandenen Daten der anderen Spalten). Gruß, Nils
  2. Moin, der Agent läuft nur auf Windows-Systemen, kann aber z.B. über SNMP auch remote andere Systeme überwachen. Gruß, Nils
  3. Moin, was auf den Lancom-Router offenkundig zutrifft. Gruß, Nils
  4. Moin, es werden keine Logins gespeichert. Auf den zu überwachenden Systemen laufen lokal Agenten (bzw. bei Systemen ohne Agent übernimmt ein Agent auf einem lokalen System die Überwachung), die dann die Ergebnisse an die Datenbank in der Cloud übertragen (Push-Verfahren). Die Cloud enthält keinerlei Zugangsdaten und auch keinen Ausschnitt der Produktionsdaten. Das Event-Logging bezieht sich standardmäßig auf System- und Applikationslogs, in denen normalerweise ja auch keine Login- oder Personaldaten stehen (was von der Applikation abhängt). Wie gesagt, ich verstehe den grundsätzlichen Vorbehalt, aber im konkreten Fall ist das durchaus diskutabel (sonst würde ich es ja auch nicht zur Bewertung empfehlen). Gruß, Nils
  5. Moin, fast alle Entwickler brauchen Admin-Rechte, weil die meisten Windows-IDEs nicht ohne laufen. Das hängt u.a. mit dem Debug-Recht zusammen, aber natürlich auch mit der Notwendigkeit, im System DLLs, COM-Vernüpfungen usw. zu verankern. Gruß, Nils
  6. Moin, das kann ich im Grundsatz verstehen, aber hier geht es ja weder um personenbezogene noch um direkt sicherheitsrelevante Informationen, sondern um Monitoring-Daten. (Das nur zur Einordnung.) Gruß, Nils
  7. Moin, du hast gerade einen der Gründe benannt, warum man ein Entwickler-Netz vom Produktionsnetz trennen sollte. Gruß, Nils
  8. Moin, natürlich. Ein generischer Fehler der Art "kann Dienst XY nicht starten" kann selbstverständlich durch Platten- bzw. IO-Probleme verursacht werden. Für das AD ist das folgenlos, das interessiert sich dafür nicht. Ich würde der Maschine aber nicht trauen, wenn sie mal eben Daten zerstört hat. Das liegt mit Sicherheit nicht am AD, sodass das Problem durch das Entfernen des AD auch nicht verschwinden wird. Gruß, Nils
  9. NilsK

    Rollback oder sowas

    Moin, ein Rollback kannst du nur für offene Transaktionen ausführen, nicht für abgeschlossene. Geht hier also nicht. Du hast zwei Möglichkeiten: 1. Letztes Backup wieder einspielen und damit die Original-DB ersetzen. 2. Letztes Backup in eine neue DB einspielen (Restore unter anderem Namen), dann per INSERT-SELECT die Daten der Tabelle aus der Restore-DB in die Original-DB übertragen. Geht natürlich nur, wenn keine referenzielle Integrität das verhindert. Gruß, Nils
  10. Moin, für mich klingt das nach einem Hardwarefehler. Die Logik des AD kann nicht die Ursache für das Problem sein, also muss sie im lokalen Betriebssystem oder in der Hardware liegen. Aus dem Grund würde ich nicht den "harten Weg" nehmen, sondern die HW prüfen und den Server neu aufsetzen. Die DC-Metadaten sollte man natürlich auf jeden Fall bereinigen. Gruß, Nils
  11. Moin, das wäre Punkt 1, den man ändern sollte. Erfordert ggf. Umkonfiguration im SAN und in den Speicherpfaden der DB, aber nicht in der Datenbanklogik. Da fehlt zwischen "dass das" und "die Vorgaben" aber ein "nicht", oder? Nein. Der Host hat auch selbst was zu tun und braucht dafür CPU-Leistung. Das ist bei allen Virtualisierern so (wie sollte es auch anders sein?), bei Hyper-V und Verwandten aber besonders. faq-o-matic.net » Hyper-V-Sizing: Virtuelle und echte CPUs Dann gibst du der VM natürlich auch nicht mehr als vier vCPUs. Siehe obiger Artikel. Gruß, Nils
  12. Moin, den Artikel von Ben kenne ich auch, aber aus meiner Sicht ist er erstens in sich widersprüchlich und wird zweitens von der Praxis widerlegt. Daher: faq-o-matic.net » Virtuelle DCs: Zeitprobleme vermeiden Gruß, Nils
  13. Moin, ihr solltet solche Aktionen nicht aufs Geratewohl unternehmen. Bei SQL Server (und anderen Datenbanken) gibt es hunderte von Faktoren, die die Performance beeinflussen können. IO gehört sicher als wesentlicher Punkt dazu, ist aber längst nicht immer die Ursache für Probleme. Sind z.B. DB und Logs getrennt? Wie sieht es mit der Nutzung der TempDB aus und wo liegt die? Sind alle notwendigen Indizes vorhanden? Gibt es Sperrkonflikte oder andere Verzögerungen durch die Applikationslogik? Ist das SAN korrekt angebunden und vom LAN getrennt? ... usw. usf. Gruß, Nils
  14. Moin, ja, das ist möglich. Gruß, Nils
  15. Moin, die Vorgaben sind ja sehr generisch und überschreiten nach meiner Ansicht den Aufgabenbereich eines Datenschutzbeauftragten. Es besteht keine Verpflichtung, eine bestimmte Firewall einzusetzen. Insbesondere gibt es in Wirklichkeit keine "Hardwarefirewall", weil jede Firewall aus Software besteht. Ich würde zwar auch keine Lancom-Firewall empfehlen, aber man trifft sowas im Feld durchaus an. Das würde ich also im Zusammenhang mit den konkreten Anforderungen bewerten. Zur Notebook-Verschlüsselung eignet sich Windows Bitlocker (wenn Hardware und passende Lizenz vorhanden) oder als kostenlose Lösung Truecrypt. Darüber hinaus gibt es noch zahlreiche kommerzielle Produkte. Beim Virenschutz kann man heute eigentlich jedes Unternehmensprodukt nehmen, viel nehmen sich die alle nicht. Lasst euch von einem kompetenten Dienstleister etwas empfehlen, der bei Bedarf auch den Support leisten kann. Der Hinweis mit dem Schwachstellenscanner ist wahrscheinlich eher ein Textbaustein. Da kann man vieles machen, aber meiner Erfahrung nach ist das bei vielen Unternehmen eher der zweite oder dritte Schritt, weil dort schon die Grundlagen nicht in Ordnung sind (Kennwortsicherheit, Systemkonfiguration, Adminrechte, Updates ...). Als kostenloses Produkt verdient der MBSA einen Blick. Wichtig sind ja vor allem Windows-Updates. Für Applikationen ist auch der Secunia PSI interessant. Auch auf Serverseite lohnt sich ein Schwachstellenscanner frühestens dann, wenn Update-Stand und Konfiguration auf aktuellem Stand sind. Gruß, Nils
  16. Moin, du weißt, dass bei Basic Auth das Kennwort im Klartext über das Netz geht? Gruß, Nils
  17. Moin, eigentlich ist GFI Max für dein Szenario gut geeignet. Die Cloud-Integration macht das Monitoring darüber hinaus unabhängig von deiner Infrastruktur. Was spräche dagegen? Gruß, Nils
  18. Moin, hier wäre jetzt die genaue Fehlermeldung und der relevante Ausschnitt aus dem Code hilfreich ... Gruß, Nils
  19. Moin, wenn ich nicht ganz falsch liege, ist der Fehler 80005000 "An invalid ADSI pathname was passed". Vermutlich sind Sonderzeichen im Namen des Users, die dein Skript nicht maskiert. Lass dir nach der Zeile "strUser = objSysInfo.UserName" mal den Inhalt von strUser ausgeben, das sollte dich auf die Spur bringen. Gruß, Nils
  20. Moin, full ack! Genau! ;) Gruß, Nils
  21. Moin, du könntest den SMTP-Server auch in eine VM installieren, die sowohl mit dem SAN als auch mit dem LAN verbunden ist. Auf dem Host hat das ja nichts zu suchen. Wobei, wie gesagt, SMTP-Verkehr im SAN nicht richtig aufgehoben ist. Gruß, Nils
  22. Moin, noch besser wäre es übrigens, den Datenbankserver per integrierter Sicherheit anzusprechen, weil man dann im Connection String kein Kennwort braucht. Gruß, Nils
  23. Moin, erstens hast du es offenbar nicht mit einem NAS zu tun, sondern mit einem SAN, zweitens siehst du gerade, warum professionelle SANs nicht nur zwei NICs haben, drittens musst du wohl in den sauren Apfel beißen und deinem SAN einen SMTP-Server erreichbar machen, wenn du Mails von dort versenden willst. Also: Routing aus dem SAN ins LAN oder einen SMTP-Server ins SAN stellen. Aus meiner Sicht beißt sich das allerdings mit der (richtigen) Anforderung, das SAN von Nicht-Storage-Verkehr freizuhalten. Um es kurz zu machen: Ich halte die Anbindung für einen Designfehler. Gruß, Nils
  24. Moin, worin soll denn da die Anforderung bestehen? Mir erschließt sich das Szenario nicht so recht. Gruß, Nils
  25. Moin, in deinem Szenario wäre vermutlich die Überwachung administrativer Zugriffe auf die Gruppen der sinnvollere Weg. Dann siehst du nicht nur, dass sich etwas geändert hat, sondern auch, welches Userkonto die Änderung ausgeführt hat. Technisch realisierst du das über die AD-Berechtigungen der Gruppen (SACL) und die Konfiguration der AD-Überwachung in der DefDomConPol. Vorsicht, das kann juristische Implikationen haben, also ggf. mit dem Betriebsrat und/oder einem Juristen abstimmen. Gruß, Nils
×
×
  • Neu erstellen...