Matrixknoten: Unterschied zwischen den Versionen
Index (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Index (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
Zeile 37: | Zeile 37: | ||
{{Hauptartikel|Betriebssystem}} | {{Hauptartikel|Betriebssystem}} | ||
Innerhalb eines Knotens fand sich auch immer ein Betriebssystem, das für den Betrieb des Knotens zwingend notwendig war, da es verschiedene Daten verarbeitete, Ressourcen verwaltete und alle weiteren Funktionen zur Verfügung stellte, die mittels User-Input dann auch genutzt werden konnten. | Innerhalb eines Knotens fand sich auch immer ein Betriebssystem, das für den Betrieb des Knotens zwingend notwendig war, da es verschiedene Daten verarbeitete, Ressourcen verwaltete und alle weiteren Funktionen zur Verfügung stellte, die mittels User-Input dann auch genutzt werden konnten. | ||
==Protokolle== | |||
Wann immer man mit einem anderen Knoten interagierte, wurden vordefinierte Matrixprotokolle aufgerufen. Darin ging es um grundlegendes, wie etwa die Überprüfung von Accountdaten, Zugriffsrechten und der Status der Verbindung. Anschließend entschied der Knoten dann, ob der Anfrage stattgegeben wurde oder nicht. Mittels spezieller Software versuchten [[Hacker]], solche Protokolle zu umgehen oder für ihre eigenen Zwecke auszunutzen, um Zugriffsrechte zu erhalten, [[Icon]]s zum Absturz zu bringen oder sonstige Dinge zu tun, die sie aufgrund ihrer Zugriffsrechte eigentlich nicht tun durften.<ref name="VN 56">{{QDE|vn}} S.56</ref> | |||
===Accounts=== | |||
Die Zugriffsrechte auf Knoten wurden mittels Accounts verwaltet. Eine jede Verbindungs- und Datenanfragen wurde mit bestimmten Privilegien ausgestattet, welche von den Account-Informationen abhingen, welche mit der Anfrage geschickt wurden oder vom ursprünglichen Login, sofern es sich um eine Subskription handelte. Dabei unterschied man in verschiedene Arten von Accounts, je nach Status der Verbindung und auch Art der übermittelten Informationen.<ref name="VN 56"/> | |||
====Standardaccounts==== | |||
Ein Standardaccount besaß Login-Daten bestehend aus Usernamen und Passwort beliebiger Länge, was eine alphanumerische Zeichenfolge sein konnte oder auch ein biometrisches Muster oder gar die Signatur eines Zugangsschlüssels. Dieses Passwort wurde entweder mit der internen User-Datenbank des Knotens oder einer anderen Quelle abgeglichen und dann entweder akzeptiert oder abgelehnt. Ein Großteil der User speicherten ihre Passwörter oder Signaturen in verschlüsselten Daten auf dem [[Kommlink]], weil diese im Regelfall schlicht zu lang und komplex waren, um sie sich zu merken. Biometrische Signaturen hingegen wurden mittels Scannern verschiedener Art direkt von den Usern eingelesen.<ref name="VN 56"/> | |||
====Knotenaccounts==== | |||
Knotenaccounts hingegen vergaben ihre Zugriffsrechte auf Knoten abhängig von den Privilegien, die der User auf einem anderen Knote besaß, mit dem er zum angegebenen Zeitpunkt verbunden war. So konnte etwa der Zugriff auf einen Sicherheitsknoten einen Useraccount und somit auch andere Rechte beinhalten, wie etwa Zugriff auf Kameras und Sensoren, die mit dem Sicherheitsknoten verbunden waren.<ref>{{QDE|vn}} S.56-57</ref> Eine [[Sicherheitsspinne]], die im Sicherheitsknoten ihre Arbeit verrichtete, hatte so auch die Befähigung, auf alle Sensoren zuzugreifen, ohne sich für jedes einzelne Gerät individuell anmelden zu müssen. Der Sicherheitsknoten verschickte diese Informationen für sie weiter, wodurch die Spinne diese Geräte dann einfach benutzen und kontrollieren konnte.<ref name="VN 57">{{QDE|vn}} S.57</ref> | |||
====Zugangs-ID-Accounts==== | |||
Auch konnte man Zugriffsrechte über eine Zugangs-ID vergeben. In der Praxis bedeutete dies, dass man jedes Mal, wenn ein Knoten oder ein Konstrukt mit einer bestimmten Zugangs-ID auf einen anderen Knoten zugreift, er oder es sofort sämtliche Zugriffsrechte erhielt, die mit dieser Zugangs-ID verknüpft waren. Dies ähnelte dem Standardaccount, da so der Knoten die Zugangs-ID mit seiner internen User-Datenbank abglich und beim Login die entsprechende Rechte verteilte. Ein Hacker konnte dies ausnutzen, indem er seine Zugangs-ID fälschte und den Knoten so zwingen konnte, ihm die zugehörigen Rechte zu geben.<ref name="VN 57"/> | |||
<!-- Ende des Artikelinhalts - Metainformationen --> | <!-- Ende des Artikelinhalts - Metainformationen --> | ||
Zeile 47: | Zeile 62: | ||
{{IdxTab | {{IdxTab | ||
| | | | ||
*{{QDE|vn}} 46, <u>52-54</u>, 55 | *{{QDE|vn}} 46, <u>52-54</u>, 55, 56-57 | ||
| | | | ||
*{{Qen|unw}} {{+idx}} | *{{Qen|unw}} {{+idx}} |
Version vom 19. Dezember 2022, 10:43 Uhr
Matrixknoten waren Teil der Topologie der WiFi-Matrix nach dem Crash von 2064, bevor diese im Rahmen von Danielle de la Mars neuen Matrixprotokollen von 2075 wieder in eine Gitter-Struktur mit Hosts, Geräten, etc. umgewandelt wurde.
Grundlagen
Wenige Jahre nach der Etablierung der WiFi-Matrix, 2070, besaß so gut wie alles einen eigenen Knotenpunkt, egal ob nun RFIDs in Kleidungsstücken, kleine Prozessoren in Kühlschränken, Kommlinks in Schmuck oder riesiger Server - sie alle waren allgegenwärtig und kommunizierten im Rahmen der Matrixinfrastruktur via Glasfaserkabel, Funkwellen, Satelliten und seltener Laser- oder Mikrowellenverbindungen.[1] Selbst Personal Area Networks waren damals nichts anderes als eigenständige Knoten.[2]
Jedes computerisierte Element, welches in der Lage war, Programme und Befehle auszuführen, bildete einen Knoten - und war als solches ein Baustein der Matrix. Knoten lieferten die Rechenleistung des globalen Netzwerkes und waren auch betretbare Orte. Berechnungen, Programme, Befehle; kurzerhand, alles, was passierte, geschah, gemäß standardisierte Matrixprotokolle in den Knoten. Dazu gehörte auch das Speichern von Daten, das Herstellen von Verbindungen und das Beleben von Personas und Agenten. Ein jeder Knoten wurde von einem Betriebssystem verwaltet.[1]
Zugangs-ID
In der Hardware eines Knotens befand sich auch immer eine Zugangs-ID, die als seine Adresse in der Matrix diente. Wenn man also den Knoten finden wollte, brauchte man nur nach dessen Zugangs-ID suchen.[1]
Personalimit
Es konnten immer nur eine begrenzte Zahl von Personas gleichzeitig in einem Knoten ausgeführt werden - wozu aber nur User zählten, die von diesem Knoten aus online gingen und nicht Personas, die von einem anderen Knoten ausgeführt wurden und nun auf diesen Knoten zugriffen.[1]
Prozessorlimit
Auch die maximale Anzahl an Programmen, die ein Knoten ausführen konnte, war begrenzt. Überschritt man diese Anzahl, wurde die Prozessorleistung beeinträchtigt.[1]
Verbindung
Jene Orte, die nur wenige Zugangspunkte besitzen, etwa wegen schlechter Infrastruktur oder aufgrund vorsätzlichen Vandalismus', konnten von der technischen Entwicklung der Matrixknoten stark profitieren, in dem die vielen Benutzerknoten selbst einen Zugang erzeugten. Die engmaschige WiFi-Matrix erlaubte jeden Knoten im aktiven Modus eine ad-hoc-Lösung, bei der sie als Router für andere Knoten um sie herum dienten. Daten wurden so von einem Knoten zum nächsten geschickt, bis dann der Zugangspunkt zur verkabelten Matrix oder das kabellose Ziel selbst erreicht wurde. Somit konnten selbst Barrens akzeptabel mit WiFi-Zugangspunkten verbunden werden.[3] Siehe auch Datenübertragung.
Arten von Knoten
Man unterschied in drei grundlegende Kategorien: Peripherieknoten, Standardknoten und Nexus.[1]
Peripherieknoten
Peripherieknoten waren Knoten, die auf Geräten existierten, wie etwa AR-Handschuhe, Credsticks, Kühlschränke, RFID-Marker, Smartguns oder Überwachungskameras und waren 2070 praktisch in jedem Gegenstand vorhanden, die nicht die Rechen- und Kommunikationsfähigkeiten von Standardknoten benötigten, aber dennoch irgendwie mit der Matrix interagierten.[1]
Anders als Standardknoten konnten sie nur eine einzige Persona ausführen und auch nur Programme, für die sie gebaut wurden. Auch ihre Betriebssysteme und Peripherieknoten waren bedeutend begrenzter und zielgerichteter. Entsprechend war es nicht möglich, das mehrere User gleichzeitig eine Persona ausführen und es gab auch nur Adminaccounts für ihren Betrieb. Allerdings war es möglich, sie zu einem Cluster zusammenzufassen, um dann gemeinsam als einzelner Super-Knoten zu fungieren. Da sie gegen Hacker aber sehr anfällig waren, wurden sie zum Schutz oft mit einer Master-Slave-Verbindung einem sicheren Knoten untergeordnet.[1]
Standardknoten
Kommlinks, Cyberterminals, häusliche Telekommunikationsanschlüsse und fast jedes andere Objekt, das tragbar und in der Lage war, eine einzelne Persona und mehrere Programme oder Agenten auszuführen, waren allesamt Standardknoten.[1] Sie konnten nur eine Persona zur gleichen Zeit ausführen, erlaubten aber per Interface, diese nach den eigenen Wünschen und Vorstellungen des Benutzers anzupassen.[4]
Nexus
"Nexus" ist ein Sammelbegriff für Hochleistungs-Mainframes, kabellose Multi-User-Arbeitsräume und Knoten mit hohem Datenaufkommen, welche zudem eine größere Anzahl von Programmen ausführen konnten, als es Standardknoten je könnten. Üblicherweise fand man Nexus in Matrixcafés, öffentlichen WiFi-Zugangspunkten, Konzernservern, Firmen mit VR-Arbeitsplätzen und Sicherheitsknoten, Datahavens und überall sonst, wo rechenintensive Aufgaben verrichtet wurden. Jene Server, die Nexus betrieben, gab es in einer großen Bandbreite unterschiedlicher Größen und Prozessorleistungen, was von Größenordnungen wie einfachen Laptops bis hin zu ausgewachsenen Servertürmen reichte. Je mehr Rechenleistung benötigt wurde, desto leistungsstärker und größer fiel auch die Hardware eines Nexus aus.[3]
Ein Nexus besaß ein höheres Prozessorlimit und erlaubte so auch, mehr aktive Programme auszuführen (wobei dies nicht Agenten, Intrusion Countermeasures, Sprites und E-Geister betraf). Ihre Konfiguration und Konstruktion war so aufgebaut, dass es möglich war, mehrere Personas auszuführen.[3]
Betriebssysteme
Innerhalb eines Knotens fand sich auch immer ein Betriebssystem, das für den Betrieb des Knotens zwingend notwendig war, da es verschiedene Daten verarbeitete, Ressourcen verwaltete und alle weiteren Funktionen zur Verfügung stellte, die mittels User-Input dann auch genutzt werden konnten.
Protokolle
Wann immer man mit einem anderen Knoten interagierte, wurden vordefinierte Matrixprotokolle aufgerufen. Darin ging es um grundlegendes, wie etwa die Überprüfung von Accountdaten, Zugriffsrechten und der Status der Verbindung. Anschließend entschied der Knoten dann, ob der Anfrage stattgegeben wurde oder nicht. Mittels spezieller Software versuchten Hacker, solche Protokolle zu umgehen oder für ihre eigenen Zwecke auszunutzen, um Zugriffsrechte zu erhalten, Icons zum Absturz zu bringen oder sonstige Dinge zu tun, die sie aufgrund ihrer Zugriffsrechte eigentlich nicht tun durften.[5]
Accounts
Die Zugriffsrechte auf Knoten wurden mittels Accounts verwaltet. Eine jede Verbindungs- und Datenanfragen wurde mit bestimmten Privilegien ausgestattet, welche von den Account-Informationen abhingen, welche mit der Anfrage geschickt wurden oder vom ursprünglichen Login, sofern es sich um eine Subskription handelte. Dabei unterschied man in verschiedene Arten von Accounts, je nach Status der Verbindung und auch Art der übermittelten Informationen.[5]
Standardaccounts
Ein Standardaccount besaß Login-Daten bestehend aus Usernamen und Passwort beliebiger Länge, was eine alphanumerische Zeichenfolge sein konnte oder auch ein biometrisches Muster oder gar die Signatur eines Zugangsschlüssels. Dieses Passwort wurde entweder mit der internen User-Datenbank des Knotens oder einer anderen Quelle abgeglichen und dann entweder akzeptiert oder abgelehnt. Ein Großteil der User speicherten ihre Passwörter oder Signaturen in verschlüsselten Daten auf dem Kommlink, weil diese im Regelfall schlicht zu lang und komplex waren, um sie sich zu merken. Biometrische Signaturen hingegen wurden mittels Scannern verschiedener Art direkt von den Usern eingelesen.[5]
Knotenaccounts
Knotenaccounts hingegen vergaben ihre Zugriffsrechte auf Knoten abhängig von den Privilegien, die der User auf einem anderen Knote besaß, mit dem er zum angegebenen Zeitpunkt verbunden war. So konnte etwa der Zugriff auf einen Sicherheitsknoten einen Useraccount und somit auch andere Rechte beinhalten, wie etwa Zugriff auf Kameras und Sensoren, die mit dem Sicherheitsknoten verbunden waren.[6] Eine Sicherheitsspinne, die im Sicherheitsknoten ihre Arbeit verrichtete, hatte so auch die Befähigung, auf alle Sensoren zuzugreifen, ohne sich für jedes einzelne Gerät individuell anmelden zu müssen. Der Sicherheitsknoten verschickte diese Informationen für sie weiter, wodurch die Spinne diese Geräte dann einfach benutzen und kontrollieren konnte.[7]
Zugangs-ID-Accounts
Auch konnte man Zugriffsrechte über eine Zugangs-ID vergeben. In der Praxis bedeutete dies, dass man jedes Mal, wenn ein Knoten oder ein Konstrukt mit einer bestimmten Zugangs-ID auf einen anderen Knoten zugreift, er oder es sofort sämtliche Zugriffsrechte erhielt, die mit dieser Zugangs-ID verknüpft waren. Dies ähnelte dem Standardaccount, da so der Knoten die Zugangs-ID mit seiner internen User-Datenbank abglich und beim Login die entsprechende Rechte verteilte. Ein Hacker konnte dies ausnutzen, indem er seine Zugangs-ID fälschte und den Knoten so zwingen konnte, ihm die zugehörigen Rechte zu geben.[7]
Endnoten
Quellenangabe
Index
Deutsch | Englisch |
---|---|
|