7. Security Considerations

Questa sezione conserva il testo RFC sul ietf-schedule YANG model, includendo recurrence groupings, iCalendar-like rules, schedule status groupings, DISMAN-SCHEDULE-MIB relationship, IANA registrations, YANG/XML examples e scheduled resource examples.

Testo RFC originale

7.  Security Considerations

   This section is modeled after the template described in Section 3.7
   of [YANG-GUIDE].

   The "ietf-schedule" YANG module defines a data model that is designed
   to be accessed via YANG-based management protocols, such as NETCONF
   [RFC6241] and RESTCONF [RFC8040].  These YANG-based management
   protocols (1) have to use a secure transport layer (e.g., SSH
   [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use
   mutual authentication.

   The Network Configuration Access Control Model (NACM) [RFC8341]
   provides the means to restrict access for particular NETCONF or
   RESTCONF users to a preconfigured subset of all available NETCONF or
   RESTCONF protocol operations and content.

   The "ietf-schedule" module defines a set of identities, types, and
   groupings.  These nodes are intended to be reused by other YANG
   modules.  The module by itself does not expose any data nodes that
   are writable, data nodes that contain read-only state, or RPCs.  As
   such, there are no additional security issues related to the "ietf-
   schedule" module that need to be considered.

   Modules that use the groupings that are defined in this document
   should identify the corresponding security considerations.  For
   example, reusing the following groupings will expose privacy-related
   information:

   *  Scheduling depends on reliable and accurate time synchronization.
      Inaccurate date and time setting can lead to scheduling events
      being triggered at incorrect intervals, potentially causing system
      failures or security vulnerabilities.

   *  Recurring events may conceal abnormal behavior or security
      threats, which may be drowned out by normal events, especially
      when they are triggered frequently.

   *  The absence of detailed logs and audit records of each occurrence
      trigger time and action results and therefore may make security
      incidents difficult to trace.

   *  Care must be taken when defining recurrences occurring very often
      and frequent that can be an additional source of attacks by
      keeping the system permanently busy with the management of
      scheduling.