HCL Domino Leap ブローシャー (2023年4月)
2023/4/19 - 読み終える時間: ~1 分
HCL Domino Leap は、1台で実現できるローコード/ノーコード Web アプリ開発・実行プラットフォームで、オンプレにもクラウドにもデプロイできる製品です。
裏表1枚のブローシャーを公開しました。今年も新しいリリースを予定しています。
証明書マネージャー (4)
2023/4/19 - 読み終える時間: ~1 分
この記事は、「Domino管理者アップデート認定試験対策」シリーズです。
最後に (かなり) 細々とした内容をカバーしていきます。
-
CertMgr が HTTP-01 チャレンジを使用して Let's Encrypt の TLS 証明書を更新する場合に使うポートは 443 ではなく 80 です。間違えやすいです。
-
証明書ストア DB (certstore.nsf) の設定手順の確認です。ACL を確認する必要があります。ドメイン内の管理者と Domino サーバーに 管理者権限と [Administrator] ロール を設定する必要があります。LocalDomainAdmins と LocalDomainServers は、デフォルトでこのアクセス権を持っています。
参考 URL: HTTP-01 チャレンジを使用して証明書要求の準備をする
-
証明書マネージャーでユーザー用 SSL 証明書を作成する際は最も強度が強いものにしたいと考えるのが普通です。V12 の証明書マネージャの ACME 構成で利用可能なキーアルゴリズムでは 4096 が最大キー長 です。
-
CertMgr タスクはキーや証明書の健全性を常に確認して、セキュリティが保たれるようにしています。そのチェック間隔は 30 分です。
参考 URL: 証明書の正常性チェック
Domino管理者アップデート認定試験対策は、残すは ID ボールト関係と管理機能関係です。もう少しお付き合いをお願いします。
証明書マネージャー (3)
2023/4/19 - 読み終える時間: ~1 分
この記事は、「Domino管理者アップデート認定試験対策」シリーズです。
-
おさらいですが、証明書管理のタスクである Certmgr は「Domino の TLS 証明書の管理」を行っています。ID ファイルや ID ボールトとは無関係です。「TLS 証明書」です。
-
証明書ストア DB に格納されている TLS 証明書はエクスポートが可能です。ただし、証明書作成時に 「エクスポート可能なキーを作成する」 オプションを選択する必要があることに注意が必要です。
-
CertMgr は、ACME アカウントおよび Let's EncryptR CA またはサードパーティ CA から生成された TLS 1.2 ホスト鍵 (キーリング・ファイル) の NIST P-256 および NIST P-384 曲線を使用した楕円曲線デジタル署名アルゴリズム (ECDSA) をサポートしています。
なにやら難しい言葉が出ていますが、要は「ECDSA 鍵は、同等の強度の RSA 鍵よりはるかに短く、一般的に RSA と同等の機能よりもパフォーマンスが向上している」ということを覚えておきましょう。セキュリティの一般常識としても覚えていて損はないでしょう。
証明書マネージャー (2)
2023/4/19 - 読み終える時間: 2 分
この記事は、「Domino管理者アップデート認定試験対策」シリーズです。
-
明書ストアから TLS 証明書をエクスポートする場合、一般的に暗号化して出力します。その際に使える形式は以下の二つです。
- PKCS12 - Binary encoded X.509 (P12/PFX)
- Base64 encoded X.509 (PEM, AES256 encrypted)
参考 URL: 資格情報をファイルにエクスポートする
-
HCL Domino 12 以降、サードパーティーの認証局 (CA) からのインターネット証明書を使って Domino の環境を構成するプロセスがより簡単になりました。V11 まではコマンドラインで keytool を実行する必要がありました。V12 では証明書ストアに文書を作成して証明書を貼り付けて処理します。その際、「チェーン内の証明書は、任意の順序で指定できる = 順序はどうでもいい」ということを覚えておくとよいでしょう。
参考 URL: サードパーティ CA からの鍵と証明書を要求してインポートする
-
Domino V12 では Let's Encrypt の証明書を容易に利用できるようになりました。Let's Encrypt には無償で証明書を提供するサービスがあり気軽に利用できるようになりました。V12 の CertMgr では、ACME プロトコルを使用して、Let's Encrypt 認証局 (CA) から TLS 証明書を自動的に要求、構成、更新できるようになりました。
Let’s Encrypt CA から証明書を受け取ると、Let’s Encrypt CA サーバーはチャレンジを使用して、ユーザーが証明書のドメイン名を管理していることを検証します。サポートされているチャレンジには HTTP-01 チャレンジと DNS-01 チャレンジの2種類があります。
おすすめは DNS-01 チャレンジで、以下のメリットがあります。
- .hcl.com のようなワイルドカード証明書をサポートしているためドメイン全体をカバーできること。HTTP-01 ではホスト単位での検証しかできません。
- パブリックインターネットから Domino Web サーバーのポート 80 にアクセスする必要ないこと。
参考 URL: Let's Encrypt CA チャレンジ・オプション
証明書マネージャー (1)
2023/4/19 - 読み終える時間: 2 分
この記事は、「Domino管理者アップデート認定試験対策」シリーズです。
インターネットプロトコルでのサービスを行うには証明書が必須です。Domino は R5 の時代から自己認証局の機能を備えていましたが、時代の流れに合わせて更新されています。HCL Domino V12 は、Domino 環境で TLS 証明書を管理するために、新しいデータベースの証明書ストア (certstore.nsf) と連携する新しいサーバー・タスクである 証明書マネージャー (CertMgr) が追加されています。
各自の Domino の利用目的によっては証明書まわりは接しない場合もあるでしょう。その場合は入念な試験対策が必要です。
-
V12.0.1 に備わっているマイクロ CAを使うとWeb サーバー TLS 証明書を比較的容易に作成できます。ただ、Micro CA で作成した証明書は、実稼働環境での使用を意図した証明書ではないことに注意してください。ファイルへのエクスポートはできません。
-
V12 では Let's Encrypt CA 使用して証明書を取り込み、使用できるようになりました。もちろん Let's Encrypt 以外の CA を使うこともできます。その場合は、証明書プロバイダとして Manual (手動) を選択します。
参考 URL: グローバル設定を構成する
-
Domino の証明書マネージャーでサポートされているキーアルゴリズムは RSA と ECDSA です。
参考 URL: グローバル設定を構成する
-
TLS の資格情報をインポートする際に使用可能な暗号化形式は PKCS12 と以下の 3 つです。
- PKCS12 - Binary encoded X.509 (P12/PFX)
- Base64 - encoded X.509 (PEM, AES256 encrypted)
- KYR - Legacy keyring format
参考 URL: TLS 資格情報をアップグレードする
HCL Notes/Domino 最新モジュール一覧
2023/4/18 - 読み終える時間: ~1 分
「どれが最新のモジュールか分からない」といったお問い合わせと時々いただきます。HCL Software のサポートでは、以下のサポート技術情報を公開しています。
HCL Domino REST API 1.0.4 をリリースしました。
2023/4/18 - 読み終える時間: ~1 分
2023年4月17日、HCL Domino REST API 1.0.4 をリリースしました。Domino データベースをセキュアに REST API でアクセスできる仕組みであり、Domino の特性を生かしたアプリケーション連携が可能になるものです。更新項目は多くはありませんが、非常に短期間で更新を重ねています。詳細は以下を参照してください。
ヘッドレスコンテンツマネジメント: ヘッドレスコンテンツマネジメントとは何か、その利点とあなたへの影響
2023/4/18 - 読み終える時間: 3 分
Headless Content Management: What Is It, Its Benefits and Implications for You の翻訳版です。
ヘッドレスコンテンツマネジメント: ヘッドレスコンテンツマネジメントとは何か、その利点とあなたへの影響
2023年4月17日
著者: HCL Digital Experience (APAC)
MACH、CMS、ウェブテック、マーテックの出版物の世界では、現在「ヘッドレス」が流行語になっています。しかし、あなたはその意味、メリット、意味を本当に理解していますでしょうか？
まず、ヘッドレスCMSの意味するところを定義することから始めましょう。Wikipediaによると、"ヘッドレスCMSはコンテンツコンポーネントのみで構成され、コンテンツ作成者のための管理インターフェース、コンテンツのワークフローとコラボレーションの促進、コンテンツのタクソノミーへの整理にのみ焦点を当てる。"とあります。
したがって、ヘッドレスCMSは、デザイン、サイト構造、テンプレートを扱う別のプレゼンテーション層と組み合わせる必要があります。この組み合わせは通常、以下の図のようにステートレスまたは疎結合のAPIに依存する：
私たちの経験では、ヘッドレスCMSのほとんどのベンダーは、ヘッドレスの以下の属性に焦点を当てています：
- RESTful な API
- マイクロサービス・アーキテクチャ
- マルチチャネル・パブリッシング
さらに、スタック全体を「as a Service（aaS）」プラットフォームで提供することも可能です。「ヘッドレスCMS」の意味を理解した上で、その意味するところを掘り下げてみましょう。
ヘッドレス CMS 導入のメリット
迷ったら、Gartner社の定める業界標準をチェックしましょう。下の図は、Gartnerによる2020年のPlatform as a Service（PaaS）のハイプ・サイクルの概要を示しています。API中心の（ヘッドレス）SaaSは、「膨らんだ期待のピーク」の端っこにあるのがわかりますね。
技術スタックにおけるヘッドレス実装（プレゼンテーション層を他のものから分離すること）は、あなたのビジネスにとっていくつかの巧妙なことを可能にします。その最も一般的な主張は、次のようなものです：
- フロントエンドの柔軟性を高め、創造性とデザインの俊敏性を向上させます。
- スタックの将来性をある程度担保できます。つまり、製品や会社のプレゼンテーションに影響を与えることなく、新しいチャネルを追加したり、他の技術コンポーネントを交換したりすることがより簡単にできるのです。
- コンテンツのパーソナライズと再利用を向上させるとともに、コンテンツ作成プロセスをスピードアップさせます。これにより、コンテンツ作成者はより多くのコンテンツへのニーズを満たすことに集中でき、フロントエンドチームはより多くのオムニチャネルのエンドポイントにシームレスにコンテンツを配信できます。
「ヘッドレスコンテンツマネジメントはデジタルエクスペリエンスのゲームチェンジャーか」 https://www.hcljapan.co.jp/software/blog/headless-content-management-is-a-digital-experience-game-changer-e2-80-8b ヘッドレスコンテンツマネジメントが、デジタルエクスペリエンスのゲームチェンジャーとなることをご覧ください。
ヘッドレスCMSの落とし穴にご注意
「ヘッドレス」とは、頭がないことを意味するのではありません。ブランドイメージ、カラー、スタイリングを持つコンテンツをチャネルに投影する何らかの方法が必要なのです。この新しいシステムは、バックエンドの制作プロセスから独立しています。
ヘッドレスCMSを採用する前に考慮すべき、潜在的な落とし穴をいくつか紹介します：
- 無限の創造性を発揮できる新たな自由を手に入れたとはいえ、デザインシステムを作成・管理するフロントエンド開発者の人またはチームが必要になります。
- このチームは、変更を加えたり、新しいチャネルを追加したりする場合に必要となります。このチームが社外にいる場合は、コストがかかります。
- コンテンツ制作のプロセスにおいて、多くの人は、コンテンツがさまざまなデバイスでどのように見えるかをプレビューすることを好みます。このプロセスでは、WYSIWYG（what you see is what you get）エディターが一般的です。この機能は、ヘッドが分離されているため、失われています。
チャネルを追加したり、デザインやレイアウトを頻繁に変更することで、ビジネス上の利点を得ることができるのでしょうか？本当に企業ブランドを継続的に編集したいのでしょうか？もしそうなら、フロントエンド・チームに無限の創造的自由を与えることは、理にかなっているかもしれません。
ベンダーにアクセス料金の請求方法を聞いてみる。市場にはさまざまな課金メカニズムがあり、ヘッドレス化の特権に関連する費用が発生することがよくあります。ヘッドレス化を決定する際には、TCOを理解していることを確認してください。
ヘッドレスの道は、気の弱い人やデジタルビジネスの初心者のためのものではありません。企業がこの変化に成功するには、かなりのデジタル成熟度と強固なチェンジマネジメントプロセスが必要です。この旅を甘く見てはいけません。
まとめ
ヘッドレスは、実際のビジネス上の問題を解決するための優れた選択肢です。フロントエンド・チームがより自由を求め、ITチームが新しいアーキテクチャ・モデルを求める場合だけではありません。そのため、すべてのステークホルダーを交えてこの決定を下すことが極めて重要です。
最新のCMSは、従来のCMSモデルではなく、コンテンツに対してヘッドレスまたは非連結のアプローチを提供します。企業は、ある時点で自社のビジネスニーズに合ったアプローチに成長できます。
デジタル・トランスフォーメーションの旅にご興味がおありですか？お問い合わせください！