general.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
<!-- splitted from ./index.xml, last change in rev 1.66 -->
<!-- EN-Revision: 96c9d88bad9a7d7d44bfb7f26c226df7ee9ddf26 Maintainer: wiesemann Status: ready -->
  <chapter xml:id="security.general" xmlns="http://docbook.org/ns/docbook">
   <title>Allgemeine Überlegungen</title>
   <simpara>
    Ein komplett sicheres System ist praktisch ein Ding der Unmöglichkeit,
    weshalb ein unter Sicherheitsprofis oft genutzter Ansatz ist, einen
    Mittelweg zwischen Risiko und Verwendbarkeit zu finden.
    Wenn jede von einem Benutzer übermittelte Variable zwei Formen von
    biometrischer Prüfung (wie z.B. ein Scan der Netzhaut und ein
    Fingerabdruck) verlangen würde, wäre eine extrem hohe Ebene der
    Verantwortlichkeit erreicht. Ein sehr komplexes Formular auszufüllen
    würde auch eine halbe Stunde in Anspruch nehmen, die Benutzer dazu
    ermuntern könnte, Wege zur Umgehung der Sicherheitsmaßnahmen zu suchen.
   </simpara>
   <simpara>
    Die beste Sicherheit ist oft unaufdringlich genug, um den Anforderungen
    zu entsprechen, ohne den Benutzer an seiner Arbeit zu hindern oder den
    Code-Autor mit übertriebener Komplexität zu überlasten. Tatsächlich
    sind einige Sicherheitsangriffe nur die Folge von allzu strengen
    Sicherheitsmaßnahmen, was mit der Zeit nur zu deren Unterminierung
    führt.
   </simpara>
   <simpara>
    Eine Phrase, die es wert ist, sich an sie zu erinnern: Ein System ist nur
    so gut wie das schwächste Glied in der Kette. Wenn alle Transaktionen
    mittels Zeit, Ort, Transaktionstyp, etc. streng mitprotokolliert werden,
    der Benutzer aber nur mittels eines einzigen Cookies verifiziert wird,
    lässt die Zuverlässigkeit für die Bindung des Benutzers an das
    Transaktions-Log bedrohlich nach.
   </simpara>
   <simpara>
    Denken Sie während der Tests daran, dass Sie selbst für die einfachsten
    Seiten nicht alle Möglichkeiten testen können. Der von Ihnen vielleicht
    erwartete Input wird zu dem eines verstimmten Mitarbeiters oder eines
    Crackers, der Monate Zeit hat, oder einer Katze, die über die Tastatur
    läuft, in keinerlei Zusammenhang stehen. Deshalb betrachten Sie Ihren
    Code am Besten aus der logischen Perspektive, um zu erkennen, wo
    unerwartete Daten eingebracht werden können und fragen sich dann,
    wie diese modifiziert, reduziert, oder weiter ausgeführt werden.
   </simpara>
   <simpara>
    Das Internet ist voll von Leuten, die versuchen, sich durch
    Entschlüsseln/Zerstören Ihres Codes, den Zusammenbruch Ihres
    Systems, Einsetzen von unangebrachten Inhalten, und anderen, Ihren
    Tag interessant gestaltenden Maßnahmen, einen Namen zu machen.
    Es ist egal, ob Sie eine kleine oder große Site haben, Sie sind
    einfach ein Ziel, wenn Sie online sind oder wenn Sie einen Server
    haben, zu dem man eine Verbindung aufbauen kann. Viele
    Cracker-Programme erkennen nicht die Größe, sondern durchsieben
    einfach gewaltige IP-Blöcke im Netz, um Opfer zu finden. Versuchen
    Sie, keines zu werden.
   </simpara>
  </chapter>

<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"~/.phpdoc/manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->