Kwalifikacje w Zawodzie - Testy zawodowe online | Egzaminy Zawodowe

KWALIFIKACJA INF3 - CZERWIEC 2014



PYTANIE NR 40.
Jakiego rodzaju mechanizm kontroli bezpieczeństwa zawiera środowisko uruchomieniowe platformy .NET Framework 4.x?
A.
B.
C.
D.
Wyjaśnienie poprawnej odpowiedzi:
W .NET Framework 4.x mechanizmy bezpieczeństwa wykonywania kodu obejmują Security Transparency Model (podział na Security-Critical/Transparent/Safe-Critical) oraz Role-Based Security do autoryzacji użytkowników. CAS był charakterystyczny dla starszych wersji i jest oznaczony jako przestarzały, więc nie powinien być wskazywany jako aktualny mechanizm.

Pełne wyjaśnienie:

Środowisko uruchomieniowe .NET Framework (CLR) zawiera mechanizmy, które wpływają na to, jaki kod może wykonywać operacje uprzywilejowane oraz kto (jaki użytkownik/rola) ma dostęp do określonych funkcji.

W .NET Framework 4.x kluczowym elementem jest Security Transparency Model. Model ten klasyfikuje kod na:

  • Security-Critical – kod uprzywilejowany, mogący wykonywać operacje wrażliwe (np. wywołania wymagające podwyższonych uprawnień).
  • Security-Transparent – kod ograniczony, który nie może wykonywać operacji krytycznych bezpośrednio.
  • Security-Safe-Critical – "bezpieczny most" (kontrolowany interfejs) udostępniający ograniczone operacje krytyczne kodowi transparentnemu.

Drugim istotnym mechanizmem jest Role-Based Security (RBS), czyli autoryzacja oparta na tożsamości i rolach. W praktyce pozwala ona rozstrzygać, czy bieżący użytkownik (IIdentity/IPrincipal) należy do roli uprawnionej do wykonania danej operacji.

Pozostałe odpowiedzi są błędne, ponieważ:

  • ASP.NET to framework aplikacji webowych, a nie ogólny mechanizm bezpieczeństwa wykonywania kodu w runtime CLR.
  • Windows API to interfejs systemu operacyjnego; nie jest specyficznym modelem bezpieczeństwa .NET Framework runtime.
  • "Mechanizm wykonywania aplikacji dla bibliotek klas" nie opisuje konkretnego, nazwanego modelu bezpieczeństwa; biblioteka klas jest typem projektu/artefaktu, a nie mechanizmem kontroli bezpieczeństwa.

Na egzaminie warto pamiętać o rozróżnieniu wersji: mechanizmy znane ze starszych wydań (np. CAS) mogą występować w dokumentacji historycznej, ale dla .NET Framework 4.x właściwe jest wskazanie modelu transparentności oraz kontroli opartej na rolach.

Dodatkowe pytania

Dodatkowe pytania (FAQ):
Co to jest Security Transparency Model w .NET Framework 4.x?
Security Transparency Model to model bezpieczeństwa w .NET Framework 4.x, który klasyfikuje kod jako Security-Critical, Security-Transparent lub Security-Safe-Critical. Określa on, który kod może wykonywać operacje uprzywilejowane, a który musi korzystać z kontrolowanych interfejsów.
Jakie są role Security-Critical, Security-Transparent i Security-Safe-Critical?
Security-Critical to kod uprzywilejowany, Security-Transparent to kod ograniczony, a Security-Safe-Critical to bezpieczna warstwa pośrednia udostępniająca część operacji krytycznych w kontrolowany sposób. Ten podział ma zapobiegać nieautoryzowanym operacjom.
Dlaczego CAS nie jest poprawną odpowiedzią dla .NET Framework 4.x?
CAS (Code Access Security) jest oznaczony przez Microsoft jako mechanizm przestarzały i w nowszych wersjach podejście to zostało zastąpione modelem transparentności. W kontekście .NET Framework 4.x poprawnie wskazuje się Security Transparency Model, a nie CAS jako główny mechanizm runtime.
Co oznacza RBS w kontekście .NET Framework?
RBS (Role-Based Security) to mechanizm autoryzacji oparty na tożsamości i rolach użytkownika. Pozwala sprawdzać, czy bieżący użytkownik należy do określonej roli (np. administrator), zanim aplikacja udostępni funkcję lub zasób.
Jak RBS działa w aplikacji .NET od strony programisty?
W praktyce RBS wykorzystuje obiekty opisujące użytkownika i jego role (np. IIdentity/IPrincipal). Programista wykonuje kontrolę dostępu do funkcji na podstawie ról, aby wymusić uprawnienia na poziomie logiki aplikacji, niezależnie od tego, czy aplikacja jest webowa czy desktopowa.
Czy ASP.NET jest mechanizmem bezpieczeństwa środowiska uruchomieniowego .NET?
Nie. ASP.NET to framework do tworzenia aplikacji internetowych. Może oferować własne mechanizmy uwierzytelniania i autoryzacji, ale pytanie dotyczy mechanizmów w runtime .NET Framework (CLR), czyli m.in. modelu transparentności i RBS, a nie warstwy frameworka webowego.
Dlaczego Windows API nie jest właściwą odpowiedzią w tym pytaniu?
Windows API to interfejs funkcji systemu Windows. Choć aplikacje .NET mogą z niego korzystać, nie jest to model kontroli bezpieczeństwa wykonywania kodu zapewniany przez CLR. Pytanie dotyczy mechanizmów specyficznych dla .NET Framework 4.x.
Jak rozpoznać na egzaminie, że pytanie dotyczy .NET Framework 4.x, a nie starszych wersji?
Najczęściej wskazówką jest wersja w treści (np. "4.x") lub terminologia: dla .NET Framework 4.x charakterystyczny jest Security Transparency Model. Jeśli w odpowiedziach pojawia się CAS, trzeba sprawdzić, czy pytanie nie dotyczy starszego zakresu; przy 4.x CAS nie jest właściwym wyborem.
Jakie błędy najczęściej popełniają uczniowie w pytaniach o bezpieczeństwo .NET?
Typowe pomyłki to: mylenie mechanizmów runtime z frameworkami (ASP.NET), przenoszenie pojęć historycznych (CAS) na .NET Framework 4.x oraz utożsamianie bezpieczeństwa aplikacji z Windows API. Pomaga zapamiętanie: 4.x = transparentność + role.
Jak przygotować się do pytań o bezpieczeństwo w .NET Framework na INF.3?
Warto nauczyć się definicji i zastosowań: Security Transparency Model (podział kodu) oraz RBS (role i tożsamość). Dobrą metodą jest porównanie wersji 3.5 vs 4.x i wypunktowanie, co jest mechanizmem CLR, a co jedynie technologią aplikacyjną (np. ASP.NET).
info

Statystycznie 40% uczniów zna prawidłową odpowiedź. trudne

Eksperci podkreślają: "CAS był charakterystyczny dla starszych wersji i jest oznaczony jako przestarzały, więc nie powinien być wskazywany jako aktualny mechanizm."

Źródła:

  • Microsoft Learn: Code Access Security (CAS) - overview i informacja o przestarzałości ("CAS has been deprecated across all versions of .NET Framework and .NET"), https://learn.microsoft.com/en-us/dotnet/framework/misc/code-access-security (dostęp: 2026-03-05)
  • Microsoft Learn: Security transparency in the .NET Framework (opis Security-Critical/Transparent/Safe-Critical), https://learn.microsoft.com/en-us/dotnet/framework/misc/security-transparency (dostęp: 2026-03-05)
  • Microsoft Learn: Changes in security policy in .NET Framework 4 (informacje o przebudowie podejścia do CAS policy w .NET Framework 4), https://learn.microsoft.com/en-us/dotnet/framework/misc/security-changes (dostęp: 2026-03-05)

Materiały:

  • Dokumentacja Microsoft Learn o Security Transparency w .NET Framework
  • Dokumentacja Microsoft Learn o Code Access Security i jego przestarzałości
  • Materiały o IPrincipal/IIdentity i autoryzacji opartej na rolach w .NET Framework
Zobacz też:

Aktualizacja pytania: 03.04.2026

Aktualizacja pytania: 03.04.2026
📡 Brak połączenia internetowego