MerakiのFirmwareのPatchと自動スケジューリングの有無

MerakiのFirmwareにはPatchの立ち位置のRelease (便宜上、Patch Release)が存在して、自動スケジューリングされるか否かはMerakiのエンジニア チームの一存で決まります。
よって、自動スケジューリングされない場合はRelease notesの情報などを元にして各自で適用可否を判断します。

Firmware Versionの表記では、ドットの3区切り目が存在するものがPatch Releaseとなります。

• Firmware Versionの書式
  <Product Name> <Major Firmware Version>.<Minor Firmware Version>.<Patch Firmware Version>

  注記: ドキュメントにPatchに関する明確な記載がなかったので、便宜上の名称としてPatch Firmware Versionと表記しております。

• 実例
  MX 16.16.5

Meraki FirmwareのPatch Release

実際の画面

• Patch Releaseが存在する場合は、メニュー: Organization > Firmware upgrades に表示されます。

  

  Firmware upgrades画面でのPatchの表示

• Patch Releaseは自動でUpgradeのスケジューリングがされる場合と、スケジューリングがされない場合があります。

  

  Patchの自動スケジューリング

• Patch Releaseの適用判断はRelease notesなどを見て行ってください。Meraki Communityで他のMeraki Userの声を聴く方法もあるかと存じます。

  

  PatchのFirmwareのRelease notes

補足

Merakiはクラウド管理型の製品であるため、Merakiデバイスの健全な状態を維持するには、Meraki Cloud側の進化に追従するようにMerakiデバイス側のFirmwareもUpgradeしていく必要があります。 そのため、自動でスケジューリングされるか否かがエンジニア チームの一存である点が気に食わなくて、サービス断時間の影響を執拗に気にするのであれば、そもそもMerakiの導入に向いていない可能性があります。 重要性があるからこそ自動スケジューリングでUpgradeが促されて、環境に依存しやすいものはUser側の判断が尊重されていると捉えるべきです。

Merakiの導入においてサービス断を執拗に気にされるケースをよく見かけるので、本記事内でも執拗に補足しております。

関連ドキュメント

本記事の執筆時点 (2022年09月頃)ではドキュメントにPatchに関する明確な記述がなかったため、サポートに問い合わせ確認を行っております。
(追記: Documentation Digest: October 28th - November 13th によると2023年10月頃に更新されました。)
下記は当時の内容の引用です。

documentation.meraki.com

Meraki Firmware Conventions
Meraki firmware nomenclature is the same across products and consists of a major and minor number as part of the name. The firmware version is named using the format given below:

<Product Name> <Major Firmware Version>.<Minor Firmware Version>

1. Major Versions

   A new major firmware is released with the launch of new products, technologies and/or major features. New major firmware may also include additional performance, security and/or stability enhancements.

2. Minor Versions

   A new minor firmware version is released to fix any bugs or security vulnerabilities encountered during the lifecycle of a major firmware release.

Meraki firmware release cycle consists of three stages during the firmware rollout process namely beta, release candidate (RC) and stable firmware. This cycle is covered in more detail in the Meraki Firmware Development Lifecycle section of this document.

下記のドキュメントにはPatch ReleaseのFirmware Upgrade Optionに関する記載はありました。(2022年09月20日に追記)

documentation.meraki.com

Security and SD-WAN Features Directory のドキュメント

関連記事

myhomenwlab.hatenablog.com

Splunk Add-on for Cisco Merakiのログ取得時の遡り期間

Splunk Add-on for Cisco Merakiのログ取得時の遡り期間は、ログの種別に応じて2パターンあります。

1. Add-onでの Inputs の設定時に、Auditログは Start from でログ取得の遡り期間を指定可能で初回のみ適用されます。

2. Audit以外のログ種別は Inputs を初めて設定したタイミングから過去24時間以内が遡り期間となります。

設定の見え方

Add-onの Inputs 設定では、Auditログのみ Start from が指定できます。

Auditログの Start from 設定

情報源

ログ取得時の遡り期間は、下記のドキュメントに記載があります。

docs.splunk.com

ログ取得時の遡り期間の記述

• Start from の情報より。

  Field	Description
  Start from	Available only for "Audit" input and applicable only for the first time. Indicates the number of days in the past this add-on should get data from. If not set, default is 1.

• 注釈の情報より。

  When you enable the input for the first time, the add-on collects historical event data for 24 hours in the past by default, or starts collection at a different time based on what you configured on the setup page (applicable only for "Audit" input).

考慮点

Audit以外のログは遡り期間が限定的なので、必要なログの取り逃しに発展しないように留意してください。

Splunk Add-on for Cisco Merakiのログ取得時の遡り期間

ログ種別: Organization Security の遡り期間の参考例

補足ですが、Meraki Dashboard APIの Get Organization Appliance Security Events では24時間を超えて遡り期間を指定可能であるため、Splunk Add-on for Cisco Merakiの挙動と混同しないように留意してください。

関連記事

myhomenwlab.hatenablog.com

Meraki CommunityのFirmware Upgrades Feed (Communityによる最新Firmwareリリースの通知)

Meraki Communityに最新のFirmwareの情報が自動的に投稿されるようになりました。

community.meraki.com

バージョンの情報は自動スケジューリングによるメール通知でも気づけますが、Organizationによって自動スケジューリングのタイミングが前後します。 また、Stable, Stable release candidate, Beta版を製品ファミリーを問わずに情報を得られます。 そのため、Firmware Upgrades FeedをSubscribeしておくと、より早く最新の情報が入手できる可能性があります。

Firmware Upgrades Feed の Subscribe

今まではMeraki Communityで @cmr 氏が有志的に新Firmwareの情報を投稿されていましたが、MerakiのTechnical Engagement Managerである Jason Moseley (@JasonM) 氏の好意もあって専用のセクションが出来上がった形です。
経緯は下記のトピックに記載があります。

community.meraki.com

最新Firmwareの情報の入手が大きな活用例になるとは思いますが、どのVersionのFirmwareがいつ頃にリリースされたのかも後追いしやすくなりました。

関連記事

myhomenwlab.hatenablog.com

Meraki MRの無線ネットワーク情報を外部公開する設定 (Public status page)

Meraki MRには無線ネットワークに関わる情報を外部に公開するための Public status page と呼ばれる設定があります。
利用用途の一例としては、公衆無線LANサービスの利用者向けに、無線APの情報を提供するような活用法が考えられます。

Meraki社が公開しているPublic Status Page

設定方法

Public status page はNetwork単位で設定する必要があります。また、Network typeがWirelessもしくはCombined hardwareのNetworkで設定できます。

設定箇所は、メニュー: Network-wide > General を開いて Status & APIs セクションの Public status page にあります。

Status & APIs セクションの Public status page 設定

設定値は3パターンあります。

設定値	挙動
Disabled: don't share any information about this network	情報を公開しません。デフォルトの設定です。
Enabled, but hide geographic locations	情報を公開しますが、地理的な情報は隠します。
Enabled	地理的な情報を含めて公開します。

Public status page を Enabled, but hide geographic locations もしくは Enabled に指定すると、Network handle の設定が表示されます。

Network handle の設定では公開用URLの一部をカスタマイズできます。他のMeraki環境 (他のOrganization)を含めて一意な文字列にする必要があります。

Network handle の設定と Public status URL

設定値によって情報の公開粒度が若干変化します。認証情報が必要なくPublicに公開されるので、不用意な有効化は避けてください。

Enabled, but hide geographic locations 選択時の Public status page

Enabled 選択時の Public status page

公開の判断に関して

防犯上の理由で公開すべきではない施設を、誤って公開しないように注意してください。

無線AP (Meraki MR)への接続端末数で人の出入りなどが推察される可能性があるため、位置情報の機密性だけでなく防犯的な面でも公開して問題ないかを確認してください。

例えば下記のサンプル画像 (ネタ画像)だと、Network名から機密性の高そうな施設だと分かり、無線AP (Meraki MR)へアソシエーションしてる無線端末数から、人や無線LANデバイス数の利用状況を推察できます。 その上で、夜間帯では毎日のようにアソシエーション数やトラフィックが減っているとすると、施設内の人員が寝静まっていて警備上の盲点になる時間帯があると侵入者は判断するかもしれません。

サンプル画像 (ネタ画像): 架空会社SampleCorp - 海洋資源極秘調査基地

関連ドキュメント

documentation.meraki.com

ThousandEyesのユニット消費の計算と、Enterprise & Cloud Agentのユニット消費の比較

ThousandEyesのユニット消費の計算方法

ThousandEyesのユニット消費の計算はURL: https://app.thousandeyes.com/calculator のUnit Calculatorから行えます。 Unit Calculatorの利用にはログインが必要で、既に設定済みのテストがある場合は自動で表示されます。

Unit Calculatorの画面サンプル

Unit Calculatorをメニューから辿る場合は、メニュー: Account Settings > Usage and Billing より Usage タブを開いて Calculate the units you need for this account group のリンクを押下します。

Unit Calculator への移動 (1/2)

Unit Calculator への移動 (2/2)

Enterprise & Cloud Agentのユニット消費の比較

ユニット消費の計算を行うにあたり特に意識しておくべきは、Enterprise AgentとClooud Agentのユニット消費になります。

下記のドキュメントに記載がありますが、Enterprise AgentはClooud Agentの半分 (2分の1)のユニット消費になります。 言い換えると、Cloud AgentはEnterprise Agentの2倍のユニット消費となります。 Enterprise Agentは自らデプロイする必要があり手間がかかりますが、その手間を惜しんでCloud Agentを積極的に利用しようとしている方は予算が想定範囲に収まるかを確認すべきでしょう。

docs.thousandeyes.com

Enterprise agents use only 1/2 the number of units that cloud agents do. See the Test Types Unit Rate Table.

下記は実際に同じテスト種別で、Enterprise AgentとCloud Agentでユニット消費を割り出した例です。

Enterprise AgentとCloud Agentのユニット消費の比較

Test Description	Interval	Details	Agents	No. of tests	Monthly Usage
DNS Server	2 min	1 servers	Cloud Agent: 1 , Enterprise Agent: 0	1	112
DNS Server	2 min	1 servers	Cloud Agent: 0 , Enterprise Agent: 1	1	56

Enterprise Agentが 56 に対して Cloud Agentが2倍の 112 になっているのが確認できます。

Cloud Agentのユニット消費が大きい点はデメリットではありますが、ThousandEyes社によって安定的な基盤上で稼働していて環境起因を受けにくい状態になっているため、End User視点からのサービスの可用性を監視するのは適しています。 一から全世界に安定稼働が必要な基盤を構築するにはコストも時間もかかるため、Cloud Agentの特性を踏まえてEnterprise Agentと使い分けてください。

ThousandEyesのEmbed Widgetで情報を外部公開する

ThousandEyesのEmbed Widgetで情報を外部公開する設定方法を記載します。 Embed Widgetは社内ポータルや障害状況の公開サイトで、サービスの状況を公開するような用途に活用できます。

Embed WidgetはThousandEyes社のServerでホストされており、誰でもアクセスが可能な状態となるので機密性が高い情報は公開しないようにしてください。

ThousandEyesのEmbed Widget

設定方法

• 任意のDashboardを開いて、公開対象とするWidgetの Option (...) ボタンから Embed Widget を押下します。

  

  WidgetのOptionからEmbed Widgetを押下

• Allow anyone to embed this widget onto external sites. のチェックを入れます。メッセージ情報の通りに、誰もがWidgetを外部サイトに埋め込みるようにするかを確認するチェック ボックスです。

  

  Allow anyone to embed this widget onto external sites. のチェック

• 外部公開用のURLが含まれたiframeのタグが発行されます。

  

  iframeのタグの発行

• 対象のWebサイトにiframeのタグを埋め込みます。簡単なテストをすぐに行えるように、下記にサンプル用のHTMLコードを用意しました。

  <html>
    <head>
        <meta charset="UTF-8">
        <title>ThosuandEyes Embed Widget Sample Page</title>
    </head>
    <body>
  ★★ iframeのタグを埋め込みます。 ★★
    </body>
  </html>
  

  

  サンプル用のHTMLコード

  

  サンプル用HTMLコードの表示

Embed WidgetのURLへの直接アクセス

生成されたEmbed WidgetのURLが分かれば、認証無しで誰でもアクセスが可能です。下記の画面キャプチャはURLを直接開いてアクセスした例です。

Embed WidgetのURLへの直接アクセス

関連ドキュメント

docs.thousandeyes.com

特定UserやGroupからのAzure Portalへのアクセスをブロックする

特定UserやGroupからのAzure Portal (https://portal.azure.com/) へのアクセスをブロックする設定方法を記載します。

一般的に考えうるセキュリティ設計だと、権限が必要なアカウント (例: 管理者アカウント)のみからAzure Portalへのアクセスを許可して、その他の権限が不要なアカウントからのアクセスはブロックするのが想定されます。 ですが、本記事内では検証用途で設定を行うため、特定UserやGroupからのアクセスを対象にしてブロックします。

特定UserのAzure Portalへのアクセスをブロック

Conditional Access (条件付きアクセス)の設定要件

Azure Portalへのアクセスを制御は Conditional Access (条件付きアクセス)を用いて行います。

Conditional Access でポリシーを有効化するにあたっては Enable security defaults の設定を事前に No にして無効化しておく必要があります。

特定UserやGroupからのAzure Portalへのアクセスをブロックする設定

Enable security defaults を無効化せずに Conditional Access の設定を行った場合は、下記のようなエラーが表示されます。

Conditional Access 設定時のエラー

It looks like you're about to manage your organization's security configurations. That's great! You must first disable security defaults before enabling a Conditional Access policy.

Security defaults must be disabled to enable Conditional Access policy.

Enable security defaults の設定に関する注意点

Enable security defaults を不用意に No に設定すると、Microsoft 365テナントのセキュリティ低下を招く可能性があります。 そのため影響範囲やセキュリティ設計を踏まえた上で設定変更を行ってください。

筆者の場合は、Azure Portalへのブロック方法の確認を行いたかっただけであるため、一時的に Enable security defaults の設定変更を行いました。

Enable security defaults の設定箇所

Enable security defaults の設定箇所ですが、Azure Active Directory の画面から Manage セクション内の Properties に移動して Manage security defaults のリンクを押下すると表示されます。

Manage security defaults の設定

Enable security defaults に関する情報

• Enable security defaults に関するMicrosoftのドキュメントは下記になります。

  docs.microsoft.com

• Enable security defaults の設定によって提供される機能は、Japan Azure Identity Support Blog のブログ記事に整理されています。

  jpazureid.github.io

アカウント セキュリティの重要性の高まりに応じて Enable security defaults は有効化が促される方向に見受けられるため、最新の情報を把握した上で設定変更してください。

設定方法

Conditional Access の設定画面への移動

• Azure Active Directory から Manage セクションの Security を開きます。

  

  Manage セクションの Security

• Security の画面から Protect セクションの Conditional Access を開きます。

  

  Protect セクションの Conditional Access

• Conditional Access の画面から Policies を開き、New policy を押下してポリシー (Conditional Access policy)を作成します。

Conditional Access policyの作成

Conditional Access policy の設定

• Conditional Access policy の設定を順に行っていきます。

  

  未指定状態の Conditional Access policy の画面

• Name には任意の名称を指定します。本記事では Test_Block_Azure_Portal としています。

  

  Name の指定

• 特定のUserやGroupを対象とするために Users or workload identities の設定を行います。

  

  Users or workload identities の設定

  • What does this policy apply to? が Users and groups (デフォルトで選択)になっているのを確認します。

  • Include から Select users and groups のラジオ ボタンを指定して、Users and groups にチェックを入れて任意のUserやGroupを指定します。

    本手順では、ブロック対象となるUserやGroupを指定してください。 対象UserやGroupからのアクセスが許可されるか、ブロックされるかは Grant の設定に依存します。そのため、Grant の設定次第でブロック対象ではなく許可対象にもなり得る点に留意してください。

• 対象のCloud appsを選択するため、Cloud apps or actions の設定を行います。

  

  Cloud apps or actions の設定

  • Select what this policy applies to が Cloud apps (デフォルトで選択)になっているのを確認します。

  • Include から Select apps のラジオ ボタンを指定して、Select から Microsoft Azure Management を指定します。

• Enable policy を On にして Create ボタンを押下します。

  

  Enable policy: On

Azure Portalのブロック画面

下記はAzure Portalへアクセスしてブロックされた際の画面です。

Azure Portalのブロック画面

ブロックされた際のエラーは下記のように表示されます。

Sign-in failed
Error code: AADSTS53003
Error message: Access has been blocked by Conditional Access policies. The access policy does not allow token issuance.