2020/9/3 - 読み終える時間: 2 分

HCL Software は全面的にコンテナ技術に対応する方向で着実に進んでいます。HCL Digital Experience も例外ではなく、対応済みです。これについての記事 What Are Kubernetes and Docker ? And Why Should They Be Part of Your Digital Solution? の翻訳版です。

Kubernetes と Docker とは？なぜ HCL Digital Solutions の一部にする必要があるのか？

2020年9月2日

著者: HCL Digital Experience Team

開発者の間では、Kubernetes と Docker という名前を耳にする機会が増えてきています。どちらもコンテナ（コードやシステムライブラリなど、アプリを実行するために必要なすべてのパーツを含むソフトウェアパッケージ）に関連する技術ですが、よくある誤解は、両者が競合するソリューションであるということです。開発者は Kubernetes vs. Docker いう議論に慣れ親しんでいるかもしれませんが、実際には、Kubernetes と Docker を併用することはコンテナ化されたアプリケーションを実行するための優れた方法です。しかし、それが何を意味するのかを理解するためには、まずそれぞれのプラットフォームが何をするのかを個別に見る必要があります。

Docker は何をするのか？

Docker は現在、最もポピュラーなコンテナプラットフォームです。開発者は自分のマシン上では完璧に動作するコードを書いても、それをプログラムに実装しようとすると失敗してしまうことがよくあります。開発者は自分のコードを一つのまとまりのあるコンテナイメージにパッケージ化し、コンテナプラットフォームをホストしているコンピュータ上で実行することができます。

企業の 30% が Docker を使用しており、その数は着実に増加しています。開発者がコンテナ化の恩恵を受けられるのであれば、そのソリューションに Docker を採用する可能性が高いでしょう。

では、Kubernetes は何をしているのか、そしてそれらはどのように関連しているのでしょうか？

Docker が何をするのか、なぜ Docker が重要なツールであるのかを理解したところで、Docker と Kubernetes の関係を理解する上で最初に重要なことは、2つの技術は根本的に異なる目的を果たしているということです。Container Journal がうまく表現しているように、" Kubernetes はコンテナ化技術を......11倍にした "ということです。

Kubernetes は、コンテナ化に伴う次の難問の解決策として登場しました。コンテナが存在している今、コンテナをどのように整理することができるでしょうか？ Docker がアプリケーションのパッケージングと配布を担当しているとすれば、Kubernetes はそれらのアプリケーションのスケーリングと監視を担当しています。このテックソリューションでは、アプリケーションを構成するコンテナを直感的なグループにまとめ、管理や検索が容易になるようにしています。

Kubernetes アーキテクチャは、急速に進化するデジタルの世界において、開発チームが俊敏性と柔軟性を維持することを可能にします。

Kubernetes を使わずに Docker を使うことも可能ですが、アプリをスケールアップして、できるだけ多くのユーザーが簡単に利用できるようにしたいと考えている組織にはお勧めできません。逆に、Kubernetes を別のコンテナ化ソリューションと併用することも可能ですが、Docker はアプリコンテナソリューションの最高峰としての地位を確立しているので、Docker と Kubernetes のコンボは市場での最高の統合であることに変わりはありません。

Docker と Kubernetes のペアリングを利用したソリューションは、アプリを数日ではなく数分でクラウドや構内にインストールできるため、開発チームの時間を節約できます。

詳細はこちらをご覧ください。ウェビナー「コンテナの入門」に参加するか、オンデマンドで視聴してください。

2020/9/3 - 読み終える時間: 9 分

REST API を使って Unica Campaign を操作する解説記事 Campaign REST API-V1 and V2 の翻訳版です。

HCL Unica Campaign REST API-V1 と V2

2020年9月2日

著者: Vishal Jadhav / Lead-Product Support Engineer

Unica Campaign は、アウトバウンド、マルチチャネル、マルチウェーブバッチキャンペーンの強力なセグメンテーション機能とトラッキング機能を備えた先進的なキャンペーン管理ソリューションです。しかし、すべてがバックグラウンドでどのように動作するのか、Campaign はスイートの他の製品とどのように接続したり、統合したりするのか。それを行うための RESTful な アプローチがあります。はい、REST API の話です。では、REST API とは何か、Campaign オブジェクトを作成する際にどのように使用されるのかは、複数の側面と領域を持つ問題です。Campaign 、オファー、オファーリスト、属性、ターゲットセルオブジェクトを操作するための HCL Campaign REST API です。

REST APIとは？

インターネットで航空券を検索して予約しようとしていて、数秒後には結果が出ている。これが API の機能であり、2つのシステムがお互いに話をするのを助けるものです。REST は、特定のルールを念頭に置いた API の作成を支援することで、このようなコミュニケーションを促進するアプローチです。

私は、Unica のサポートエンジニアとして、またクライアントアドボケイトとして働いていますが、さまざまな Unica のユースケースや質問に出くわします。私が観察してきたことの一つは、REST API コールを使用して Campaign オブジェクトを作成する際に、プラットフォームで必要な設定を行うのに苦労しているということです。課題は、サンプル JSON ボディの使用、API コールの実行に必要なパラメータ、または REST API の任意のバージョンの構成値の更新のように、さまざまな場合があります。この記事では、プラットフォームでの設定を理解し、実行するために役立つことに焦点を当てています。REST API の呼び出しを実行するためには、REST API の呼び出しを操作しながら、多くのユーザーやクライアントに利用されている Postman ツールを使用します。

プラットフォーム側の設定

1. APIコールで認証に使用されるトークンの有効期間を延長します。

• 次へナビゲートします: Affinium|Manager|miscellaneous

• 必要に応じてトークンのライフタイムの値を増やします。秒単位です。

2. 2. API 認証の設定を変更します。

• Affinium|suite|security|apiSecurity|manager|managerAuthentication に移動します。

• すべてのプロパティを無効にします。

• 「API アクセスに認証を必要とする」を true にしておくと、API コールに使用されたユーザーのパスワードが検証されます。

• 設定＞ユーザーからユーザーにパスワードを設定してください。無効にしている場合は、パスワードを渡す必要はありません。

3. Affinium|suite|security|apiSecurity|manager|Logout に移動し、以下のように設定値を変更します。

4. Rest API Ver1.0の更新設定

• Affinium|suite|security|apiSecurity|Campaign|Campaign REST API V2 Filterに移動します。

• 設定値を更新します。下のスクリーンショットを参照してください。

• アプリケーションサーバーを再起動します。

APIコールを実行する Postman ツール

Postman はソフトウェア開発ツールです。これは、人々がAPIへの呼び出しをテストすることを可能にします。Postman のユーザーはデータを入力します。データは特別な Web サーバーのアドレスに送信されます。通常、情報が返され、Postman はユーザーに提示します。任意のツールを使用することができますが。主な目的は、API コールをしようとしている間に必要な詳細を提供することです。呼び出しタイプ、リクエストパラメータ (ヘッダ、ボディ) 、実行に必要な URL などのパラメータがあります。

1. POST API コールを実行してトークンを取得し、認証のための API コールで使用できるようにします。

<span style="font-weight: 400;">Call: POST</span>
URL : http://<HostName:Port>/unica/api/manager/authentication/login/
Headers :
M_user_name > user used for API calls for e.g. asm_admin
M_user_password > password set for user.

2. このトークンIDは、Campaign rest API の API コールを任意に投稿する際に使用できます。オファーをリストダウンします。

Call: GET
URL : http://<HostName:Port>/ Campaign/api/campaign/rest/v2/offers/search?search
Headers :
m_user_name  > asm_admin
m_tokenid         > <TokenID captured in platform post call>
api_auth_mode > manager

「検索」文字列では、任意の文字列値を渡すことで、特定のオファーを検索できます。

REST V2の例

特定のオファーの詳細をリストアップします。

Call: GET
URL : http://<hostname:port>/Campaign/api/campaign/rest/v2/offers/29
Where 29 is offerID . Pass any offer ID for which you need to fetch the details.
Headers :
m_user_name > asm_admin
m_tokenid > <TokenID captured in platform post call>
api_auth_mode > manager

レスポンス .

Campaign でオファーを作成するには？

Call: POST URL : http:///Campaign/api/campaign/rest/v2/offers

• Header

  m_user_name > asm_admin
  m_tokenid > <TokenID captured in platform post call>
  api_auth_mode > manager
  Content-Type > application/json

• クエリパラメータでは、以下の値を渡します。 securityPolicy: 例えば 'Global Policy' などのポリシー名。 folderid: オファーを作成する必要があるフォルダID。 templateName: Campaign オファー作成のためのオファーテンプレート名。

• Body. 行のラジオボタンを選択し、JSON ボディを送信します。 それは、オファー名とパラメータを持っています。パラメータが渡されていない場合は、デフォルトのパラメータ値でオファーを作成します。

[ {
"offerName":"RESTNewOffer_IP1",
"attributes":[]
} ]

REST V1 の例

Campaign オファー作成のための v1 rest APIを 実行するには？

• 設定手順はすべて先ほど定義したものと同じです。
• 同じ手順でプラットフォームの tokenID をフェッチします。

• 唯一の違いは、APIコールで渡す必要があるデータの入力タイプです。 v2では、入力データを生のJSONとして渡していることがわかりました。 v1では、すべてのパラメータを x-www-form-urlencoded として渡す必要があります。

  Call: POST URL : http:///Campaign/api/campaign/rest/v1/offers

Headers :

m_user_name > asm_admin
m_tokenid > <TokenID captured in platform post call>
api_auth_mode > manager

コンテンツタイプを追加する必要はありませんが、選択する入力タイプで自動的にピックアップされます。 Body セクションの x-www-form-urlencoded のラジオボタンを選択し、以下の値を入力してください。

securityPolicy: Policy name for e.g. ‘Global Policy’
folderid: folder ID under which we need to create offers for e.g. 4 [root folder for offers]
templateName: campaign offerTemplate name from which offers to be created .
BulkOfferInfo : [{"offerName":"Offer API","attributes":[]}]

オファー名とパラメータを渡します。パラメータを渡さない場合は、デフォルトのパラメータ値でオファーが作成されます。リクエストとレスポンスは以下のスクリーンショットを参照してください。

オファーのパラメータを渡したい場合は、必要に応じてパラメータ値を追加して、リクエスト本文を更新します .

BulkOfferInfo:
[
{"offerName":"Offer Interact API_3",
"attributes":[
{"type":"TextAttribute","name":"ABC_TXT","value":"XYZ"},
{"type":"DecimalAttribute","name":"UACIInteractionPointID","value":2.0},
{"type":"TextAttribute","name":"UACIInteractionPointName","value":"IP2"}
]
}]

Campaign REST API の呼び出しにより、Campaign オブジェクト (オファー、キャンペーンの作成) の create+update+delete+List のような操作を Unica アプリケーションにログインすることなく実行することができます。Campaign とREST API の連携については、お気軽にお問い合わせください。

2020/9/2 - 読み終える時間: 3 分

製品から離れて、セキュリティーの一般論を今日は紹介してみたいと思います。HCL AppScan - The New Hybrid Security Employee の翻訳版です。

HCL AppScan: 新しいハイブリッドセキュリティーー担当者の姿

2020年9月1日

著者: Rob Cuddy / Global Application Security Sales Evangelist

「ゲームをしよう (Shall we play a game?)」という言葉を聞いて何を思い浮かべるでしょうか？

もしあなたが私の世代なら、1983年に戻って、若いマシュー・ブロデリック（『(フェリスはある朝突然に Ferris Bueller's Day Off)』から数年後）とアリー・シーディ（『セント・エルモス・ファイア (St. Elmo’s Fire)』や『ブレックファスト・クラブ (The Breakfast Club)』から数年後）が、人気映画『ウォー・ゲーム (War Games)』の中で地球熱核戦争のゲームを始めるのをすぐに思い出すことでしょう。多くの人にとって、これが私たちが初めてサイバーセキュリティーを知ったきっかけでした。

そして数十年後の今でも、サイバーセキュリティーといえば、多くの人が思い浮かべるのはこれです。

画像提供：Giphy のご厚意による

40年近く経った今でも、コントロールルームやセキュリティー・オペレーション・センターは非常に存在感があり、私たちを守るために必要なものですが、確かにサイバーセキュリティーに対処する必要があるのはこれらの場所だけではありません。脅威の状況がますます増加し、脆弱性の数も増加している中で、可能性のある攻撃や脅威の媒介をすべて処理するために、高度な訓練を受けた専門家の小さなグループを一室に集めて依頼するのは、非常に不公平なだけではありません。危険です。

Edgescanの 2020 Vulnerability Statistics Report では、「専門家の 64%が、組織の Web アプリケーションやエンドポイントを完全に認識していないことを認めた」とし、2019年には 80億件以上のレコードが侵害されたことにも言及しています。そして、コンテナ、マイクロサービス、モノのインターネット (IoT) の普及はそれを難しくしているだけです。

つまり、単一分野のセキュリティー専門家に頼るという古いモデルは、特にDevOpsのスピードで動いている場合には通用しないということです。今日、成功した安全なソフトウェア開発には、複数の分野にまたがるアプローチと人材が必要とされています。今日と明日のセキュリティー社員は、どのような姿をしているのでしょうか？よくぞ聞いてくれました。

セキュリティー従業員の新しい種類

先日、Application Paranoia のポッドキャストでは、HCL Software の CISO である Joe Rubino にインタビューを行い、当社が行うすべての業務において、信頼されたセキュリティーの強固な文化を構築することについての彼の考えを尋ねました。その中心にあるのは、組織とその顧客基盤をサポートするセキュリティー専門家のチームをどのように構築し、育成しているかということです。

私たち全員が非常に興味深かったのは「セキュリティーのプロとは何か」という概念を広げる議論でした。皆さんも「セキュリティーはみんなの仕事」という言葉を聞いたことがあるのではないでしょうか。確かにその通りだと思います。結局のところ、私たちは個人的なデバイスを持ち歩き、日常的に個人的な資産と職業的な資産の複雑な組み合わせを使用しています。私たちは皆、自分の役割を果たす責任があります。私たちは、これらのデバイスを更新し、適切に使用し、フィッシング詐欺のような明らかなものを避けるようにしなければなりません。

これらは素晴らしいことですが、今日の真のセキュリティーには、より全体的な対応が求められています。ジョーはこのように表現しています。"私たちは皆、セキュリティーの専門家としての責任を負わなければなりません。データプライバシーの専門家の。カスタマーサポートのプロ。そして、その新しい通常の状態、期待、それに伴う責任を受け入れるように自分自身を追い込むことができればできるほど、私たちはさらに進歩していくでしょう。

で、セキュリティーの専門家って何ですか？

明らかに、セキュリティーは常に進化し、複雑さを増している高度に技術的な領域です。この分野で成功するためには、技術的なスキルを理解し、適応し、適用し、学ぶ能力が成功の前提条件となります。

しかし、優れた技術力だけでは、もはや十分ではありません。

今日では、特にセキュリティーに関わる分野では、従業員のハイブリッドモデルをさらに導入する必要があります。 ジョーが "学際的なアプローチ "と呼ぶものが必要です。これは、人々はいくつかの重要な分野でスキルを持っていますが、ビジネスのニーズが変化し、新しいスキルが登場しなければならないため、それらのスキルセットだけに頼ることはできないという考え方です。

ポッドキャストでは、そのような従業員を見つけ、育成することについて、成功への鍵がいくつか言及されていました。その中でも特に重要なのは、次のようなことでした。好奇心旺盛で、共感力のある人を見つけること。これは、より多くの組織が DevSecOps のプラクティスを採用するように努力しているので、特に重要である。好奇心と共感は問題解決とチームワークを促進し、DevOps と DevSecOps の長期的な成功に不可欠な文化を構築します。

セキュリティー専門家のメンタリティが、単に「このチェックリストを実行してください。完了！」という考え方では、必要とされる包括的なセキュリティーを提供することはできません。また、ポリシーの施行や規制の遵守だけではいけません。その代わり、セキュリティー対策は継続的に評価、評価され、ビジネスニーズの変化に応じて調整されなければなりません。適切に実施されれば、優れたセキュリティーは消費者の信頼と信頼を促進します。これにより、「当社はお客様のデータに対して責任を持っています」と宣言することができます。

「決められていることだから」の意識から距離を置く

我々は正しい理由で正しいことを行い、多くの人がセキュリティーの専門家だと思っているようなチェックリストのような考え方を避けているのだろうか」という、重要なレトリック的な質問をジョー氏は投げかけました。

素晴らしい質問です。

今日、セキュリティーは単なるゲートキーパーではなく、ビジネスを可能にする存在である必要があります。つまり、セキュリティーの専門家は、ビジネスとの連携が必要なのです。セキュリティーはもはやサイロで運営することができないため、コラボレーションの増加を意味します。また、コラボレーションには、あらゆるレベルで効果的な感情的知性、共感性、リーダーシップが必要である。これは、潜在的なリスクを認識するだけでなく、ビジネス価値の観点からリスクを評価できることを意味します。要するに、セキュリティーに対する考え方は、「NO」の声が聞こえる場所から、「YES、そして、安全に行う方法はこうだ」というのが当たり前の場所へと変化しなければならないのです。

良いセキュリティーがあれば、より速く進むことができる。

その通りです。優れたセキュリティー対策がソフトウェア開発ライフサイクル (SDLC) 全体に十分に統合され、すべての段階で意味のある実用的なフィードバックがチームに提供されると、リスクの監視、管理、最小化、緩和がより適切に行われるようになります。 その結果、システムに構築された信頼性が高まり、全体的な展開が短縮されます。

「決められた」という考え方から離れることができれば、莫大な利益を得ることができます。特に、安全なコーディングの分野があります。安全でないコードを書こうとしている開発者にはまだ会ったことがありません。彼らは正しいことをしたいと思っています。彼らは、機能する安全なコードを書きたいと思っています。しかし、あまりにも多くの場合、私たちは開発者が成功するためにはセキュリティーの「専門家」になる必要があると考えています。しかし、それは真実ではありません。開発者が専門家になる必要はありませんが、開発者全員がより安全になる必要があります。

実際に、説明しましょう。あなたがどこかに車を運転していて、突然、車のダッシュボードがクリスマスツリーのようにライトアップされ、エンジンがストールしたとしましょう。あなたは車を停めて、車を降りてボンネットを開け、問題を解決できる可能性が低いことを知っていました。突然、あなたの後ろに車が停車する音がして、誰かがやってきて、あなたのそばに立ってしばらく見ていました。そして、エンジンのランダムな部分を指差して「そこに問題があります」と言うと、あなたが返事をする前に、彼らは自分の車に戻って、車に乗って走り去ってしまうのです。あなたがたまたま経験豊富なメカニックで、手元に正しい部品を持っていない限り、彼らが問題を指摘するだけでは、あなたを助けるためには何の役にも立たないのではないでしょうか？

欠陥追跡システムからセキュリティー問題についてのメールを受け取る開発者のようなものです。

私はしばらく前に主要なセキュリティーカンファレンスにいましたが、私が訪れたほぼすべてのブースでは、「開発者をセキュリティーに関与させる」ということについて、何かしらの趣向が凝らされていました。その根底にある考えは、開発者がスキャンをして報告を受けることで、何がどこに脆弱性があるのか、より多くの情報を開発者に提供することができれば、もちろん開発者はそれを修正する方法を知っているだろうというものでした。これを聞いたとき、私が最初に思ったのは「頑張ってください！」ということでした。現実には、開発者がそのレベルのセキュリティーの専門知識を求めているのであれば、すでにそれを達成しているはずだからです。

実際のところ、安全なコーディングは大変な作業です。そして、やりがいがあります。そして、それには複数の視点が必要です。機能が満たされていることを確認するためにコードレビューを行うという概念は理解していますよね？では、セキュリティーの専門家と開発者が、脅威のモデル化やセキュリティーレビューのようなことで一緒にパートナーを組むのは良いアイデアではないと考えるのは、本当に大げさなことでしょうか？重要なのは、セキュリティーの専門家は、もはやテストを実行して発見した脆弱性を報告するだけでは済まないということです。そうではなく、開発チームと協力して、バランスを取り、優先順位をつけ、修正するために積極的に働く必要があります。これこそが、共有学習を促進することなのです。

まとめ

つまり、今日のビジネスを成功させるためには、技術的なスキルだけでなく、リスクを軽減するためのより良いコラボレーションを推進するための根性、共感、好奇心を持ったセキュリティーとセキュリティーの専門家に対する新しいチームベースのアプローチが求められているということです。ビジネスリーダーは、このようなコラボレーションを大規模に推進するための環境、プラットフォーム、さらにはインセンティブを提供し、チーム間やパイプラインを通じて信頼を高め、最終的には、より優れた、より安全なソフトウェアをより迅速に提供することにつながるようにする必要があります。

これらやその他のアプリケーションセキュリティーに関する議論については、Application Paranoia ポッドキャストをチェックしてください。

2020/9/2 - 読み終える時間: 2 分

継続的なセキュリティーに関する連載の最終回、HCL AppScan - Assure Continuous Security の翻訳版です。

HCL AppScan - 継続的なセキュリティーの確保

2020年9月1日

著者: Colin Bell / SALES DIRECTOR 共著: Rob Cuddy / Global Application Security Sales Evangelist, Kristofer A Duer / Architect for research projects at HCL AppScan

第 1 回目の継続的セキュリティーに関するブログでは、3 つのテーマ分野の概要を説明し、それぞれに 2 つの重要な機能が含まれていることを説明しました。シリーズ最終回となる今回のブログでは、「保証 (Assure)」のテーマと、「測定 (Measure)」と「監査 (Audit)」の能力に焦点を当てていきます。

では、なぜ「アシュア」を選んだのでしょうか？ それは、あまりにも多くの場合、セキュリティーがプロアクティブよりもリアクティブであることに気づいたからです。実際、Ponemon Institute の 2018年の調査によると、サイバーセキュリティーおよび情報セキュリティーチームの 78%が誤ったアラートに対処するために週に 250時間以上（合計で）を費やしていたという驚くべき結果が出ています。私たちはより良い方法で対処する必要があります。正しく行われている適切なセキュリティープログラムは、ビジネスに付加価値を与え、システムへの信頼感を高め、非生産的なことに費やす時間を減らすことができます。すべてのアラートが実際に問題なのかどうかを理解しようとして時間を無駄にするのではなく、セキュリティープログラムの真の保証が必要です。

継続的なセキュリティーでは、プロセスから学び、改善することを目的としています。例えば、あるチームが継続的なサニタイズの問題に悩んでいるとしたら、安全なコーディング教育を強化する必要があるかもしれません。また、ある脆弱性が多くのチームに渡って暴露されている場合は、コーディングガイドラインを修正する必要があるかもしれません。成功するためには、ガイドラインと基準を満たすための管理が確実に行われていることを確認する必要があります。成功を測定するためにはメトリクスが必要であり、目標を確実に達成するためには監査が必要です。

測定

測定能力は、継続的なセキュリティーを成功させるための重要な側面の一つです。このケイパビリティでは、セキュリティーの具体的な側面である測定値と、それらの測定値が互いに関係している関係、およびビジネスとの関係である測定値の両方を調査します。この両方に注意を払い、プロセスの成熟と進展に合わせて正しく適用する必要があります。この能力は、多くの組織でアプローチが異なる点でもあります。例えば、私は、リリース前にアプリケーションをスキャンすることが最も重要な測定値であるというケースを見てきました。残念なことに、これは、スキャンによって発見された結果を重視していません。そう、スキャンは実行されましたが、もし、その結果が何も行われなかった場合、それはビジネスにどのような価値を与えるのでしょうか？一般的に、このアプローチの根本的な理由は、プログラムが PCI DSS などのコンプライアンスのニーズから推進されていることです。

その他の企業は、ポートフォリオ内のアプリケーションの総数と比較して、テストされたアプリケーションの数をコアメトリクスとして評価しています。これらの組織では、多くの場合、「王冠の宝石」や最も重要な重要アプリケーションから開始し、それらがある程度のレベルのセキュリティーポリシーを満たしていることを確認しています。おそらく、アプリケーションが次のフェーズに進む前に、すべての高リスクの問題が緩和されているものと思われます。

より成熟した組織は、脆弱性を修正するための時間を短縮するために測定値を使用し、チームベースの測定値を使用して、脆弱性がどこに出現したか、あるいはどこで作成されたかを判断します。このことは、第５話「アプリケーションパラノイア」のポッドキャストシリーズで、HCL Software の CISO である Joe Rubino 氏とのディスカッションを通じて強調されました。ルビノ氏が重要視していた主要なメトリクスは、カバレッジエリアと範囲、ソース別の脆弱性の特定、特定された脆弱性の種類、過去の傾向と比較して時間の経過とともに新たに出てきたもの、そしてそれらの発見に対してチームがどのように対応していたか、というものでした。

Joe氏はまた、彼のチームにとって重要な指標が「開発チームから何を聞いているか」に関連していることにも言及しています。開発チームからは、脆弱性やセキュリティー全般についての懸念があり、その懸念が彼らの作業負荷にどのような影響を与えているか？セキュリティーチームは、その負担を軽減するために、どのようにプロセスを改善できるのでしょうか？彼の指摘は、これが単なる一方向的なコミュニケーションフローではないことを確認する必要があり、全員が同じチームの一員であると感じていることを確認するための指標を使用する必要があるということです。

どのようなアプローチであれ、最終的に重要なのは、メトリクスがセキュリティーガバナンスの観点から推進されることであり、その逆ではないということです。例えば、ビジネスリスクに基づいてアプリケーションのテストプロセスの概要を説明したり、スキャンにどのようなタイプのポリ シーが適用されるかを決定する安全なコーディングガイドラインを含めることができます。これは、どのようなリスクを受け入れ、どのようなリスクを修正する必要があるかについての決定に直接つながります。ガバナンスがうまくいっていれば、何を測定すべきかをよりよく知ることができ、その情報を使って、私たちが望む結果に影響を与えることができます。

監査

これは、セキュリティー監査の活動にうまく連れてきてくれます。多くの組織では、これは独立した機能であり、重要なアプリケーションのセキュリティーテストやアプリケーションのペンテストを担当しているかもしれません。過去にこのような活動をしてきた経験から、これらのチームは非常に熟練しており、脆弱性を探すことになると、岩が発見されないようにする能力に誇りを持っていることを知っています。

問題は、彼らの作業が長く、何百ものアプリケーションを持っている会社にとっては、規模が大きくならないことです。SDLC で行われたセキュリティーテストを常に活用しているとは限りません。また、実施されているテストの種類をレビューすることもありません。

継続的なセキュリティーでは、監査も重要な要素であり、企業のセキュリティーは、開発から運用に至るまでのセキュリティープログラム全体に責任を持つべきである。監査は、一連の規則や規則に対するコンプライアンスを検証するだけのものではありません。監査とは、ビジネスが健全に機能するように、ポリシー、慣行、手順が正しく実行されているかどうかを検証することです。ペンテストは一つの機能ですが、単独で行うべきではありません。むしろ、収集したメトリクスを見直し、脆弱性の知見を報告書に反映させるなど、企業の全体的なセキュリティー戦略の中に収めるべきです。

SIEM を使用している場合、その情報は、アプリケーションとその露出リスクに関する意思決定を行うためにも活用されなければなりません。すべての活動から情報が収集されると、この情報は、必要に応じてプロセスを変更するためにガバナンスにフィードバックされることがあり、また、フィードバックされるべきである。これは、チームに教育を提供して、セキュリティー意識を強化したり、脅威モデルに影響を与えたり、セキュリ ティ基準やガイドラインを変更したりすることができるかもしれません。このことが意味するのは、監査は、アプリケーションの全体的なリスクを決定する上で重要な側面であるということです。

まとめ

つまり、継続的なセキュリティーの成功を保証するための柱は、監査、測定、ガバナンスが共に働くことである。本質的には、ガバナンスは、プロセス全体でセキュリティーテストがなぜ、どのように行われているかを概説し、メジャーはテストに関する事実を示し、監査は、それが望ましいレベルで機能しているかどうかを確認することです。

今回のブログでは、Assure のテーマと Measure と Audit の機能に注目しました。これで、継続的なセキュリティー連載は終了です。

このシリーズの以前の記事を見逃してしまった方は、こちらからご覧いただけます。

第1回: AppScan - そろそろセキュリティも継続的に行う必要があります

第2回: HCL AppScan - 継続的なセキュリティーの構築

第3回: HCL AppScan - 継続的なセキュリティーの強化

2020/9/1 - 読み終える時間: 2 分

HCL Accelerate はさまざまなツールと連携して追跡ができるようになっています。今回は SAP との連携についての紹介です。How to map and trace changes to an SAP application using HCL Accelerate の翻訳版です。

HCL Accelerate を使用して、変更内容を SAP アプリケーションにマッピングしてトレースする方法

2020年8月31日

著者: Brian Stump / Product Specialist

HCL Software のバリューストリーム管理ツールである HCL Accelerate を使用すると、バックログから本番までのソフトウェアデリバリープロセス全体を追跡できるようになります。HCL Accelerate を使用してSAPアプリケーションのプロセスを追跡する方法については、引き続きお読みいただくか、以下のデモビデオをご覧ください。

この例では、SAP アプリケーションの UI に小さなテキストの変更を加えます。この変更は、Jira、SAP Web IDE、GitHub、Jenkins、ServiceNow を含む当社の DevOps パイプラインを通過しますが、これらはすべて HCL Accelerate との統合によってマッピングされています。

Accelerate のバリューストリームビューは、パイプラインで使用されるツールを自動マッピングすることで、Solution Manager での作成から SAP Cloud Platform でのデプロイまでの変化の流れをマッピング、可視化、解釈します。動画の自動マッピングは以下のように行われています。

まず、SAP で作業項目を作成して、タイトルの Web UI に変更を加えます。この変更は Jira と連携します。Jira で、デプロイ用に選択するワークアイテムを更新します。HCL Accelerate のバリューストリームビューでは、ドットで表される SAP ワークアイテムが "backlog" ステージから "selected for development" ステージに移動したことがわかります。

次に、SAP Web IDE で変更を加え、その変更を GitHub の開発ブランチにコミットしてマージします。このコミットには作業項目 ID が含まれており、これが、HCL Accelerate がその項目を Jira にリンクする方法です。HCL Accelerate で値のストリームに戻ると、SAP のドットが「進行中」の状態に移動していることがわかります。その後、この変更をマージするために GitHub でプルリクエストを作成すると、SAPドットが HCL Accelerate で「マージ済み」の状態に移動します。

項目がマージされると、Jenkins で自動的にビルドが開始されます。このビルドが完了すると、Jenkins はそのビルド情報を HCL Accelerate に渡し、SAP ドットは自動的に「ビルド」状態に移行します。Jenkins が SAP を介したデプロイを完了すると、SAP ドットはデプロイ先の開発環境に移動します。

これらのドットの移動は、単に作業アイテムがパイプラインのどこにあるかを視覚的に確認するだけのものではありません。ワークアイテムがバリューストリームに沿って移動すると、対応するデータが HCL Accelerate に送信されます。パイプラインのどの段階でも、ドットをクリックすると、そのアイテムの完全な変更履歴、関連するワークアイテムやプルリクエストが表示されます。HCL Accelerate の「インサイト」セクションでは、パイプライン内のすべての作業項目からのデータを使用したダッシュボードや詳細なレポートを見ることができます。すぐに使えるダッシュボードを使用して、ビルド数やデプロイメントチャートなどを追跡したり、カスタムレポートを設定して、ビジネス独自の主要なパフォーマンス指標を追跡したりできます。

HCL Accelerate の DevOps パイプラインの視覚的な「ドット」表示により、作業項目がどこにあるかを簡単に確認することができます。また、すでに使用しているソフトウェア開発ツールを接続するための簡単な統合機能により、HCL Accelerate は、DevOps データの単一の真実のソースとなります。無料の Community Edition で HCL Accelerate を今すぐご利用ください。

2020/8/29 - 読み終える時間: ~1 分

Virtualizing Middle-Tier and Back-end Applications の翻訳版です。

HCL OneTest: 中間層およびバックエンドアプリケーションの仮想化

2020年8月28日

著者: Nabeel Jaitapker / Product Marketing Lead, HCL Software

テストプロセスの間、異なる開発チームが異なる速度で移動するという事実により、配信はしばしば課題となります。

例えば、モバイルチームは毎日確実にリリースできるかもしれません。しかし、ミドルウェアチームは毎週のようにリリースし、メインフレームチームはリリースに1ヶ月以上かかるかもしれません。

目標が継続的なデリバリーであれば、自動テストを行っても、この問題がボトルネックになる可能性があります。

HCL OneTest Virtualization は、不足しているシステム・コンポーネントをシミュレートして、より迅速な開発とテストを可能にします。実際のサービスと同じ方法でネットワーク・トラフィックをリッスンするため、実際のサービスが利用できない場合でも開発とテスト活動を継続することができます。

さらに、受信メッセージをチェックし、それらのメッセージを処理し、記述された動作に従って応答します。

HCL OneTest Virtualization は、元の環境を再構成することなく導入することができ、時間を節約し、エラーを回避することができます。

HCL OneTest Virtualization の詳細については、こちらをご覧ください。

2020/8/29 - 読み終える時間: 3 分

How HCL Launch enables enterprise-level DevOps の翻訳版です。

HCL Launch がエンタープライズレベルの DevOps を実現するしくみ

2020年8月28日

著者: Madhavarao Kulkarni / Associate General Manager

業界を超えた迅速なソフトウェア開発の需要の高まりにより、複雑なDevOpsのセットアップが必要になることがあります。開発ライフサイクルの短縮、デプロイの失敗の減少、コミュニケーションの効率化、コスト削減などの高度な機能が、DevOpsソリューションとサービスの需要を後押ししています。市場投入スピードの重要性が高まる中、企業は迅速な開発とデプロイメントのためにDevOpsソリューションを採用し、手動プロセスを大幅に削減してコーディング・エラーを削減しています。

これは実際にはどのようなものなのでしょうか？ HCL Launch は、最も複雑なデプロイメントを処理し、大企業のために迅速なソフトウェアのアップグレードを可能にするように構築されています。

図: HCL Launch がメインの IT アプリケーションとして使用される典型的な継続的デリバリーパイプライン

エンタープライズユースケース - DevOps を実現する単一の IT Webフォーム

開発チームが、ボタンをクリックするだけで簡単にインフラを手に入れたいと思っていると想像してみてください。開発チームは、簡単なフォームに記入して、物事を完了させるために IT に助けを求めるでしょう。このプロセスは、開発ツールやビルド＆パッケージツールからは単純に見えますが、デプロイメントフェーズやリリースフェーズからは複雑になります。しかし、デプロイフェーズからリリースフェーズになると複雑になります。

複雑なフェーズ

複雑な組織では、以下のような主要なグループがそれぞれ異なる方法でITを管理しており、それぞれが好ましいツールを持っています。効果的な DevOps を提供するためには、すべてが単一のフォームの下に置かれなければなりません。

• オンプレミス、クラウド向けの IT インフラストラクチャのプロビジョニングツール
• 開発と継続的な統合ツール
• デプロイメントとリリースツール
• ユーザーアクセス管理ツール

HCL Launch は、多くのITツールのセットと統合するのに適しており、継続的なデプロイメントを実現するために、開発チームの要求をそれにマッピングするための簡単なオプションを提供します。HCL Launch の大きな特徴の1つは、テンプレートのコンセプトを通して、IT ヘッドの「シングルフォーム」インフラストラクチャの要求を満たしていることです。ユーザーのウェブフォームで定義したものが、HCL Launch のテンプレートとして機能します。

デプロイとリリースのフェーズでは、以下のことを効率的かつミスなく完了させる必要があります。

• アプリケーションを、異なるスクラム/マイクロサービスチームによって開発されたいくつかの成果物の束として可視化する
• 異なるバージョンの成果物を含むアプリケーションを、成果物に変更を加えることなく、安全に Dev-QA-Stage-Prod 型の環境にスムーズに移行させる
• デプロイ、ロールバック、監査を週単位で数回実施する
• この規模のオンプレミスとクラウドインフラへのデプロイメントで 100 のアプリケーションをサポートする
• 適切なチームが成果物のデプロイの適切なセットで動作していることを確認する
• 自動および手動の承認プロセスのオプションを提供する
• 成果物を取得し展開するために、IT ツールに広い範囲で統合する

最後に、異種プロセスを管理し、追跡するのは非常に複雑なので、すべてのエンタープライズアプリケーションが同じ成熟度レベルに入ることを保証する責任があることを覚えておいてください。あなたは、上記の各質問のテンプレートを用意しておく必要があります。これを超えて、成功した DevOps は以下のことを必要とします。

• 最高レベルのフルアプリケーションをデプロイするためのオプションを提供すること
• アプリケーションのフルリリースではなく、影響を受けるモジュールやコンポーネントに基づいて部分的にデプロイすること
• 可能な限り迅速かつ容易なロールバック

複雑なフェーズを単純化するための HCL Launch のキーコンセプト

HCL Launch では、以下のように、ソフトウェアアプリケーションを可視化するための非常にシンプルな定義を提供しています。

• アプリケーション
• コンポーネント
• 環境への取り組み
• リソース
• プロセス
• チーム
• カスタマイズを制御するプロパティ

これらのキーコンセプトを適用することで、上記のユースケースで見てきたすべての基準を満たすような小規模なアプリケーションや大規模なアプリケーションを定義できます。

なぜ HCL Launch がここで正しい選択なのでしょうか？

• テンプレート: HCL Launch は、アプリケーション、コンポーネント、エージェント、プロセス、リソース、チームなどのテンプレートを提供します。

• API ファーストのアプローチ: HCL Launch は API ファーストのアプローチを信じており、APIを介してほぼすべての機能を提供しており、あらゆる規模の企業に容易に統合できます。

• サーバ & エージェントのモデル: アプリケーション・リソースを簡単に定義し、必要に応じてプラグ・プレイができます。デプロイメントのためのインフラストラクチャの健全性と稼働時間を確保するのに役立ちます。

• プラグインを使った IT ツールとの連携・統合: HCL Launch が提供するいくつかのプラグインは、最も一般的なDevOpsツールとの統合を可能にし、デプロイとオーケストレーションのプロセスを定義します。また、独自のツール用に独自のプラグインを作成できます。

• デプロイメントカレンダー: シンプルなデプロイメントカレンダーを保持して、ITにおける全体的なデプロイメントを可視化します。

• コンプライアンスのための監査？デフォルトでは、すべての活動を追跡するために監査情報を提供し、デプロイメントは、コンプライアンスのためにいつでも参照してください。

• 成長管理: デプロイメントに最適なものを提供する場合、HCL Launch を使用したアプリケーションの数の増加を期待できます。HCL Launch は、HAトポロジー、エージェントリレー、アクティブアクティブサーバー、分散フロントエンドなどを提供します。

よく定義された継続的なデプロイメントは、エンタープライズ向けの強力なリリース管理プラクティスを可能にし、よく定義された継続的なデプロイメントは、HCL Launch によって達成されます。

2020/8/28 - 読み終える時間: ~1 分

"The Truth about Migrating from Domino to Microsoft (Mail Edition)" と題する記事が Domino People 社のサイトに掲載されています。Domino People 社はアイルランドにある HCL のビジネス・パートナーです。

同社は、HCL Notes/Domino を中心とする HCL のコラボレーションのビジネスを基本としていますが、Domino から他のプラットフォームへの移行希望がないわけではなく、実際にそのようなビジネスを手がけています。その経験を踏まえて経験したこと、見えてきた課題が書かれています。

他社記事のため、内容をここに掲載できませんが、ご興味のあるかたは読んでみてはいかがでしょうか。普段は気づかない Domino のメリットが見えてくるかもしれません。